Using the Right Tools

Designing applications for the server poses a number of interesting problems that dont occur in client-side application development. Several advantages compensate for these problems, however, one of the largest advantages being the ability to tune your application for the hardware and environment on which it will run.

Its extremely important that development teams set up a laboratory system that mimics their production environment as closely as possible. This laboratory is useful right from the start of application development, as it allows for continuous gathering of application data, which when stored as metrics provides a measurable system for monitoring an application.

Its critical that data on performance, scalability, and reliability be monitored throughout application development. There are many benefits to developing software with this sort of infrastructure:

• Problems can be detected early (right after introduction), making debugging easier (smaller code path ).

• Environmental issues ( especially in terms of performance and scalability) can be better understood , and the application can be better tuned for environmental specifics from the start.

• The team has very good ideas on the maximums for the system. The best performance, scalability, and reliability in the production environment can be determined and used as ideal goals for the final application.

An important part of gathering these metrics is using the right tools to measure them and using the right tools to help you quickly find and fix problems in your application. In the following sections youll look at just some of the tools that will help you get the most out of your application.

Profiler

A profiler allows the your team to understand where the application is spending most of its time. In the development of ATL Server, profilers were used constantly on test applications in order to understand bottlenecks, so that performance tuning could be tailored to where it was most needed.

Numerous times, the ATL Server design team saw situations where developers (of end applications) would try to fix perceived performance issues without ever using a profiler. Occasionally, the developers had picked the worst area of their applications, and sometimes they were completely off track. The one fact that always bore true was that developers would get at least a 10 percent performance improvement by running a profiler and spending a week or two examining and acting on the results.

Although performance must be designed into an application, its important to use a profiler often to ensure that silly coding mistakes, or unknown side effects of APIs or third-party libraries, arent greatly degrading performance of an application.

Profilers can also help identify if the problem isnt in the application itself, but in your data access or network communication.

Perfmon

ATL 7.0 ships with some new Perfmon utility classes that make using the NT Perfmon system easy. In Chapter 9 we spent some time reviewing the ATL Server support for Perfmon. This functionality can be very useful to help monitor your application performance during the development cycle.

Perfmon data is very easily to collect and store, and it has the advantage of being viewable from remote locations. Thus, whether youre gathering Perfmon data from your development machines or from your laboratory setup, its always easy to quickly get and analyze the data that youre interested in.

In particular, you should use Perfmon to measure metrics of concern, such as CPU utilization, memory utilization, use of resources, or time spent using resource such as files, handles, and so on. You should be sure to analyze this data (you can use the many tools available for analyzing Perfmon data or you can generate your own) to look for unusual behavior in your application.

Task Manager

Often overlooked by developers, Windows Task Manager is often the fastest way to discover problems in your latest coding changes. Task Manager is capable of viewing numerous pieces of data in real time on your application, including CPU utilization, memory utilization, and utilization of other resources such as handles.

With Task Manager, you should look for real-time, telltale signs of poor application coding. Good examples include erratic CPU utilization and resource leaks. Major resource leaks in particular are easily picked up with Task Manager. You can easily watch the memory utilization for your application increase over time or the number of handles your application has open slowly increase with each incoming request. In your laboratory setup, you can use Task Manager to quickly detect these mainline problems. Task Manager is not 100 percent accurate; instead, use it to gauge obvious trends (i.e., leaks), as opposed to using it for reliable metrics (i.e., working set).

Web Stress Tool

A Web stress tool such as Microsoft Application Center Test (ACT) is also a must-have in your arsenal of tools. This type of tool is designed to stress Web applications over long periods of time and allow for analysis of performance and other data during these runs.

A Web stress tool will help you best simulate how your application will respond in a real-world environment (especially if you run the tool on your application in a controlled laboratory environment). Can your application handle the number of clients that its supposed to? Is your application quickly becoming database or network bound under stress? Is your high CPU utilization indicative of unnecessary locks in your code?

The performance numbers from this kind of tool are more meaningful than simple closed-network or (even worse ) localhost testing. Theyre realistic (if your laboratory is realistic) and can show problems in your application at high loads.

A Web stress tool is also designed for testing the reliability of your application, and you should ensure that you leave the tool pounding your server for several days at a time. With these long stress runs, you should look for signs of trouble such as your application returning error pages. Its in these long runs that youll discover the smaller memory and other resource leaks in your application. Once again, Perfmon is your good friend in recording the data required to find these problems.

A Web stress tool is a great way to find serious problems in your server application, particularly in terms of reliability and performance under realistic (or heavy) loads. By completing these tests in your laboratory, youll get a feel for how your application will work in the real world. Also, because many problems manifest themselves only under these stressful conditions, youll have a great environment to debug reliability and performance problems in your application. It sure beats having to debug them on a production server!

Putting It All Together

By using all these tools in conjunction, youll be able to gather and record specific metrics for your application. When you keep a constant measure of these metrics, you can quickly diagnose and resolve many problems such as the following in your application:

• Sudden drops in performance (remembering that in a server application, even a 10 percent performance hit can kill an applications response time) can be quickly found and solved .

• Newly introduced memory or handle leaks are much easier to track down when the team knows the new code path(s) introduced in which the leaks must occur.

• Changes in database performance and response time can be identified and correctly attributed to changes in the application or in the layout/structure of the database itself.

Recording and monitoring the metrics of your application is also the best way to determine which hardware configuration best suits your application. Maybe there are problems that you didnt expect to have, such as a very high load on your internal communications (lots of internal data exchange) or poor scalability from your application.

The laboratory environment and the use of these tools also allow you to discover how your application should be tuned for the production environment. You should fine-tune thread pools, buffer sizes, and the like in the laboratory environment to ensure that your application will run at its best.