Chapter 6: WebSphere Platform Performance, Tuning, and Optimization


In this chapter, you'll get down and dirty with WebSphere performance. You'll look at the top issues associated with WebSphere performance and learn how to extract the most from your platform. You'll also look at WebSphere from an architectural viewpoint and see how to best deploy and optimize your applications (post-development) to ensure maximum operational performance.

The Need for Speed

I'm one of those people who get a warm-and-fuzzy feeling inside when I see high-performing , well-optimized, and well- tuned environments. It says to me that the people responsible for this environment take care and pride in what they do, and chances are that everything about the environment (not just the performance) is nicely designed and managed.

You could liken the art of optimizing a computer system to spending your weekends polishing and tuning a sports car. Specifically, the WebSphere performance methodology you explored during Chapters 1 and 2 is akin to polishing and tuning your sports car. It's this methodology that helps you ensure a constantly high-performing and well-tuned WebSphere application environment.

Things change over time within your environment. To use the sport car analogy, the oil level changes, the weather changes, your driving habits change, and so forth. All of these factors affect the level of optimization of the car itself. WebSphere is no different. Although this analogy somewhat oozes clich , there's a close similarity between WebSphere and a sports car because they both need constant monitoring. You should be able to set up some scripts and tools (which I'll discuss in later chapters), and WebSphere should tell you when things are becoming a little rough around the edges.

What kind of things will change over time? How long is a piece of string?

In the world of Internet-based applications and e-commerce, trends and usage change constantly. Although there's some cyclic trend to most of the load characteristics from a microworld perspective, over time, 99 percent of applications will need to be tuned. Additional customers, additional system load, increased amounts of data requiring more and more Central Processing Unit (CPU), memory, disk storage, and so forth are all aspects of a system that need constant management and care.

The Methodology for Optimization

In Chapter 1, you saw a methodology that you can use to tune and manage the performance of your WebSphere environment. It's important that you follow a methodology even if it's not the one I suggested. Although there's some overhead in following a methodology, it does promote a controlled and managed approach to optimization. You need to know and track what settings change what factors of performance in what ways. Furthermore, you need to be able to start to plot the changes and the impact of those changes over time.

I tend to look at a tuning and optimization strategy as a large panel of switches and knobs . Each turn of a knob and each flick of a switch will cause a different result. Because of the vast number of combinations that are possible from the huge array of setting options available within WebSphere, it's imperative that the approach for tuning is controlled. Following the methodology each time makes sure that what you're tuning (and ultimately changing) doesn't affect other dependant components .

The methodology, known as the Mirrored Waterfall Performance Methodology (MWPM), works in such a way that it helps you know what dependant components may be affected by your tuning efforts. For example, you can't change your application's data persistence layer or database reliance without looking at what the effects will be on components such as the Java Database Connectivity (JDBC) pool manager. This is even more evident if you're using something such as Container Managed Persistence (CMP). With CMP, you rely on a well-tuned WebSphere platform, so any poor results in performance are the result of an incorrectly sized system or incorrectly tuned and optimized settings.

Finally, if you do change a setting in WebSphere and the results are favorable, it's prudent to check all downward components (down the model) even if the initial results seem promising. You may make the changes inadvertently during a quiet period, and although the results of your changes to, let's say, a JDBC connection pool manager are promising , you may have thrown the whole queuing model of your environment out of whack.

So, plan, test, plan, test and then implement.

Know What You're Changing

I have a problem with managers who attempt to manage something they don't understand. This is similar to architects who attempt to architect something that they themselves can't or shouldn't develop. The same applies to systems managers and environment specialists such as those reading this book. Although you may be a developer or have been a developer in the past, don't fall into the trap of being a system manager/administrator and not being fully versed in Java code.

That's not to say that you need to be a developer guru, but you should be able to understand or at least read the Java code and understand the basic fundamentals of the Java 2 Enterprise Edition (J2EE) stack, what each piece means, and why each piece is used.

Most of this is well beyond the scope of this book, but I suggest you get your hands on a good J2EE/Java architecture book (http://www.sun.com/j2ee) or attend a course to understand more about Java and J2EE.




Maximizing Performance and Scalability with IBM WebSphere
Maximizing Performance and Scalability with IBM WebSphere
ISBN: 1590591305
EAN: 2147483647
Year: 2003
Pages: 111
Authors: Adam G. Neat

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net