In choosing a performance optimization strategy for your application, you should carefully choose what to optimize and avoid wasting time optimizing the wrong things. As a general rule, you shouldn't try to optimize everything in your application.
Your performance goal should be based on the needs and expectations of both the application and the user. For example, speed might be a major concern for completing a sales order in a point-of-sale application, whereas application size might be most important for a component that will be downloaded by way of the Internet.
You cannot always optimize for multiple characteristics. Typically, an approach that optimizes size compromises on speed; likewise, an application that is optimized for speed is often larger than its slower counterpart. For this reason, recommended optimization techniques in one area may directly contradict suggestions in another.
It's important to note that optimization is not always completely beneficial. Sometimes the changes you make to speed up or trim down your application result in code that is harder to maintain or debug. Some optimization techniques contradict structured coding practice, which may cause problems when you try to expand your application in the future or incorporate it into other programs.
As a general guideline, you should maximize performance and scalability using native Windows NT facilities for threading, scheduling, asynchronous I/O, and other system functions wherever possible. In other words, leverage the strengths of the operating system rather than re-create them again.
For More Information For information on monitoring your application's use of memory, disk I/O, CPU, objects, threads, and processes, see Using Performance Monitor in this chapter.
While the following optimizing suggestions are not exhaustive, you can use these as a starting point for learning more about designing and implementing high-performance applications.
Microsoft's distributed COM (DCOM) supports communication among objects on different computers, different networks, and even the Internet. With DCOM, you can distribute your application to the locations that make the most sense for your customer and the application's design requirements.
Using DCOM, your application's components can coordinate with other applications and their components, sharing information, processes, and resources across the entire infrastructure of your application. If you are designing a new distributed application that must scale well, DCOM is the solution.
While it requires some effort to reach a thorough understanding of DCOM, the application design benefit is that you can create efficient, scalable objects for use in your enterprise application. Even better, the data access or business service components you create for your application are easily reusable in other applications.
For More Information For more information on DCOM architecture, search online for "DCOM Architecture" in MSDN Library Visual Studio 6.0.
The basic unit of execution in Windows NT is the thread. Each process contains one or more threads. When a component has one thread of execution, code for only one object can execute at any given time. The Automation feature of the Component Object Model (COM) handles this situation by serializing requests. That is, the requests are queued and processed one at a time until all have been completed.
It's typically much faster to use multiple threads for simultaneous processes. Of course, the processes are never really simultaneous with a single CPU because the CPU is handling only one thread at a time. But as resources become available (or extra CPUs or memory is added), the additional threads are serviced more quickly and throughput is typically enhanced.
In a multithreading operating environment such as Windows NT, serialization protects single-threaded objects from overlapping client requests — that is, from code in a property or method being executed while one or more previous client requests are still being executed.
To use threads effectively, it's important to understand the implications of the various thread properties and how your application should use them.
For More Information For more information using multiple threads, search online for "Multithreading for Rookies" in MSDN Library Visual Studio 6.0.
Unless your application is doing tasks like generating fractals, it's unlikely to be limited by the actual processing speed of your code. Typically, other factors — such as object services, network delays, or disk activities — are the limiting factor in your application. However, you may find points in your application where the speed of your code is the controlling factor, especially for routines that are called frequently.
There are several techniques you can use to increase the real speed of your application, including those described in the following table.
| Coding technique | Comments |
| Choose data types carefully. | For example, use Long integer variables for integer arithmetic. |
| Use constants whenever possible. | Constants are resolved with compilation, whereas variables must be looked up each time. |
| Cache frequently used properties in variables. | Your application can get and set the value of variables faster than those of properties. |
| Load modules only as needed. | Otherwise, the application startup time will be excessive. |
| Reduce the number of controls on the visual interface. | More controls cause slower loading. |
| Reduce the number of active dialog boxes. | Each dialog box, whether visible or not, consumes a significant amount of memory. |
| Use early binding of COM objects. | With late binding you do not get compile-time type checking, and each reference at run time requires extra processor work. |
| Minimize cross-process calls. | Cross-process calls take a long time. |
| Minimize explicit and implicit type conversions. | Explicit and implicit type conversions require extra time. |
| Where possible, use variables instead of arrays. | Accessing an array is always slower than accessing a simple variable. |
| Use arrays instead of COM collections when passing large amounts of data. | COM collections require additional time to marshal the data. |
| Use Integer or Long data types for controlling loops. | Depending on the language, some choices, such as Variant or Double, are extremely slow. |
| Remove all dead code before compiling. | All those unused routines create unnecessary bloat. |
| Pass arguments to in-process components by reference. | The server can read the arguments directly. |
| Pass arguments to out-of-process components by value. | This avoids marshaling. |
| Where possible, use multi-use objects instead of single-use objects. | This uses less memory when loading multiple instances. |
| Use callback mechanisms rather than events. | Callback mechanisms are faster than events. |
| Avoid string concatenation. | String concatenation is a slow process. |
For More Information For more information on service queuing with Microsoft Message Queue Server (MSMQ), see Performance Value of Service Queuing with MSMQ in this chapter. For more information on object pooling using Microsoft Transaction Server (MTS), see Performance Value of Object Pooling with MTS in this chapter.
If your application uses Microsoft® Internet Information Server (IIS) and Active Server Pages (ASP), there are two significant factors in improving IIS capacity, response time, and reducing "Server too Busy" messages. These are:
Configuring the IIS queue is important because busy Web sites are defined by a high-transaction volume. Ideally, each transaction has a very short life cycle. Under a high load, significant slowdowns (blocking) can occur when a component gets called at a greater rate than the number of transactions per second the component can satisfy. When blocking occurs, incoming requests are placed in a queue for later first in/first out processing. If the blocking only occurs for several seconds, the queue smoothes out and the request is handled in a timely fashion. However, when the blocking lasts for a longer period of time (such as 30 seconds or more), an effect called "queue saturation" may occur. Queue saturation happens when the number of queued services exceeds the maximum number allowed (RequestQueueMax) and IIS returns a "Server too Busy" message.
It's not possible to automatically calculate what the optimum number of IIS queued services should be. Rather, it requires careful analysis of typical and peak loading conditions and a determination of what your target response time should be. For example, say your user response time must be 10 seconds or less. It does absolutely no good to queue more requests than can be processed in that amount of time. The whole point is to configure the queue size to handle short-term peaks and limit the queue's backlog during extreme workloads.
Tuning the IIS threads has to do with effective computer use. Allowing more threads generally encourages more CPU use. Fewer threads suggest low processor use. For example, if you have a busy site, the queue length never goes up, and the actual processor use is low, you probably have more computer capacity than required. On the other hand, if the queue length goes up and down and the CPU use is still low, the threads should be increased because you have unused processor capacity.
Ideally, you should be getting processor use above 70 percent during peak loads. While 70 percent processor use is merely a guideline, anything less suggests other limiting constraints on your application.
Note Determining the ideal queue size and number of IIS threads requires a monitoring tool (such as the Windows NT Performance Monitor) to analyze processor and thread behavior. For an introduction to using Performance Monitor, see Using Performance Monitor in this chapter.
There are many additional performance ideas that can improve your Web application's response time. Be sure to explore the performance tuning tips available from the Web sites referred to in the following note.
For More Information For more information on how to correctly size your application's IIS queue and thread usage, see http://www.microsoft.com/isn/techcenter/tuningIIS.htm. For additional tips on improving the performance of an ASP-based application, see http://www.microsoft.com/workshop/server/toc.asp.