Better Software - March 2008 - (Page wp2)

(continued from previous page) tune it. When your preproduction environment is properly tuned, then you can safely move the configuration information into production. Because we try to tune our environment in pre-production to validate settings before moving them to production, it naturally follows that we are tuning our environment to support the load test scripts that are executed against the environment. The process of tuning an enterprise application is to first implement some best practice settings, load test the application, observe its behavior and adjust the configuration parameters appropriately. It is an iterative process where we try to hone in on the optimal configuration s e t t in gs . S o m e ch a n g e s w ill y i e l d improvements and some will actually degrade performance. That is another reason why performance tuning should not be left until the end of a development lifecycle as they are time intensive. Given that we tune our application servers to our load scripts, what does that tell you about them? It tells you that load scripts really need to represent real-world user behavior. Consider tuning a web search engine. We can write a test script that searches for apples and bananas all day, but is that what end users are doing? We can tune our environment to be the best “apples and bananas” search engine in the world, yielding world-class performance, but what happens when someone searches for BEA or IBM? In our application, we could have grouped technical companies in a separate database from fruits and vegetables, so that piece of code would never be executed in pre-production and our tuning efforts would be in vain. The better solution is to discover the top 1000 or 10,000 search phrases and their frequencies. Then, compute the percentage of time that each is requested and build test scripts that request those phrases in that percentage. For the remaining percentage balance, you might connect the load test generator to a dictionary that queries for a random word. The difficult part of writing user-representative load scripts is the process of discovering how your users are using your applications. It is not an exact science, but for reasonably reliable results, the first step is to look at your access logs. It is not recommended that you do this by hand because the task is insurmountable for even a web application of medium size. There are plenty of commercial or free tools that will analyze your access logs for you. They will do the following: • Sort service requests by percentage of time requested and display that percentage • Zoom in and out of your analysis time period to present finer or lesser granular results • Identify peak usage times of the day, week, month and year • Track bytes transferred and mean time of requests • Identify and categorize the originators of requests against your application (internal, external, and geographic location) • Summarize the percentage of requests that were successful • Summarize HTTP errors that occurred • Summarize customer loyalty, such as return visitors and average session length • Track page referrals from other sites advanced tool that can monitor your usage and partition business functions by request parameters. Access logs give you part of your solution— the next step requires a deeper understanding of the application itself. For example, when a particular service request is made, you need to know the various options that control its behavior. The best sources of that information are application use cases and the architect responsible for that functionality. Remember that the goal of the exercise is to identify realworld user behavior, so your research needs to be thorough. Errors at this stage will lead to the aforementioned “apples and bananas” search engine anomaly. For a more holistic approach to capturing a reliable and detailed understanding of enduser behavior, you may want to consider Quest’s User Experience Monitor. This application sits between your end users and your web servers. It captures—in real-time— every single request that passes though your environment. It provides the most extensive set of data describing exactly what the real users are doing, including connection speeds, desktop browser versions and aggregation by geography/domain. And all of this is provided with zero overhead to the application via passive network sniffing technology. About Quest Software, Inc. Quest Software, Inc. delivers innovative products that help organizations get more performance and productivity from their applications, databases and Windows infrastructure. Through a deep expertise in IT operations and a continued focus on what works best, Quest helps more than 50,000 customers worldwide meet higher expectations for enterprise IT. Quest Software can be found in offices around the globe and at www.quest.com. Regardless of the software that you choose to analyze your access logs, the important thing is that you perform the analysis and use this information as a starting point for building your test scripts. Access logs are somewhat limited in what they report and may not suffice in certain instances, such as when you use a single URL as the front controller for your application and dif ferentiate bet ween business functions by embedded request parameters. In this case, you need a more To read the rest of this white paper, visit www.quest.com/JavaTesting © Copyright Quest® Software, Inc. 2008. All rights reserved. Quest is a registered trademark of Quest Software, Inc. in the U.S.A and/or other countries. All other trademarks and registered trademarks are property of their respective owners. The information in this publication is furnished for informational use only, does not constitute a commitment from Quest Software Inc. of any features or functions discussed and is subject to change without notice. Quest Software, Inc. assumes no responsibility or liability for any errors or inaccuracies that may appear in this publication. Quest-BetterSoftware-12717-Q22008 http://www.quest.com http://www.quest.com/JavaTesting

Table of Contents Feed for the Digital Edition of Better Software - March 2008

Better Software - March 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: Breaking Ground On SOA Software Development Worst Practices Mind the Gap Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.