[Go] server performance and scalability Killer

Server Performance and Scalability Killer
George v. Reilly
Microsoft Inc.
February 22, 1999
Directory
Preface
Application Server
The flexibility and performance of IIS
10 Commandments to stifle server performance
Conclusion
--------------------------------------------------------------------------------
Preface
Server performance issues are now a problem for many people writing desktop applications. The success of the Component Object Model (Component object model,com) and Component Ware produces an unexpected result, which is that if you use an application server such as an ASP (an extension of IIS), you don't have to write host code. In fact, the previous host code is not in the real server environment to write. There are many important differences between the desktop environment and the server environment, and these differences can have unpredictable effects on performance.
Desktop Application Server
The factors that affect desktop application performance are well known. Long instruction paths mean slower code, which is a major flaw in performance. Using large amounts of resources makes your application even more bloated, so that other applications in the system will have fewer resources available. Slowing startup times can irritate users. Too many run settings increase the machine's page error rate, slowing them down and reflecting dullness. Server applications are also often affected by these factors, and other factors are described below:
Typically, there are no hundreds of or dozens of clients that the server application handles at the same time. For desktop applications, it's very quick to respond to users in 1/10 seconds. Assuming that an operation requires a full 100ms, the application can do only 10 operations in a second. Most server applications require a much larger amount of flux than 10 requests per second. High latency Network (latency = message transmission time) increases the response time, which requires the server to respond faster to meet the requirements.
Server applications often handle a large number of data settings. Inefficiencies, especially those that waste running time, cannot be used to process millions data.
Server machines are more powerful than desktop machines. The server machine has more memory, larger disks, faster CPUs, and usually has multiple processors. But these are still not enough. Desktop machines deal with sporadic bursts of business, most of the time is idle, and the server's load is continuous. Server machines are expensive and must run well.
The server application needs to have a normal running time of months. After a while, the performance of the server must not be reduced by the accumulation of resource leaks or cruft (a data structure and statistical results that require periodic cleanup).
Most server applications need to adopt a multithreaded architecture. Consider processing only one request at a time. The performance of a single-threaded server, which spends most of its time on I/O, is difficult to accept. The thread pool can process several requests at the same time using other idle processor clock cycles. To take full advantage of multiprocessor systems, server applications must be multi-threaded. Unfortunately, multithreaded applications are difficult to write, are difficult to debug, and are hard to run, especially in multiprocessor systems. But once you get it right, the performance goes far beyond the same single-threaded application, and from that point of view, it's worthwhile to use multithreaded applications.