Pay attention to IIS server performance Ten things you can't do

The performance of the IIS server is related to our work efficiency, so there is no way to hinder the performance of the IIS server, but many people will still make some mistakes and cause the performance of IIS to be impaired. Now, check out what can't be done. of.

1. Multiple objects should be allocated and freed

You should try to avoid over-allocating memory, because memory allocation can be costly. Releasing memory blocks can be more expensive because most allocation operators always attempt to connect adjacent freed memory blocks into larger blocks. Until Windows NT® 4.0 service pack 4.0, in multithreaded processing, the system heap usually runs badly. The heap is protected by a global lock and is not extensible on multiprocessor systems.

2. Should not consider using processor cache

Most people know that hard page faults caused by virtual memory subsystems are expensive and best avoided. But many people think that there is no difference in other memory access methods. Since 80486, this view is not right. Modern CPUs are much faster than RAM, RAM requires at least two levels of memory cache, high-speed L1 cache can hold 8KB of data and 8KB of instructions, while slower L2 cache can hold hundreds of kilobytes of data and code, mixed with data and code. Together. A reference to a memory region in the L1 cache takes one clock cycle, a reference to the L2 cache takes 4 to 7 clock cycles, and a reference to the main memory requires many processor clock cycles. The latter number will soon exceed 100 clock cycles. In many ways, caching is like a small, high-speed, virtual memory system.

As for the basic memory unit associated with the cache, it is not a byte but a cache column. The Pentium cache column is 32 bytes wide. The Alpha cache column is 64 bytes wide. This means that there are only 512 slots in the L1 cache for code and data. If multiple data are used together (time position) and not stored together (spatial location), performance will be poor. The spatial position of arrays is good, and the list of interconnected lists and other pointer-based data structures tend to be poor.

Packaging data into the same cache column will generally improve performance, but it will also degrade the performance of multiprocessor systems. It is difficult for the memory subsystem to coordinate caching between processors. If a read-only data used by all processors shares a cache column with a data that is used by one processor and updated frequently, the cache will take a long time to update the copy of the cache column. This Ping-Pong high-speed game is often referred to as "cache sloshing". If the read-only data is in a different cache column, sloshing can be avoided.

Space optimization for code is more efficient than speed optimization. The less code there is, the less pages the code occupies, which requires fewer run settings and fewer page faults, and fewer cache columns. However, some core functions should be speed optimized. Profilers can be used to identify these functions.

3. Never cache frequently used data.

Software caching can be used by a variety of applications. When a calculation is expensive, you save a copy of the result. This is a typical time-space compromise: save some time by sacrificing some storage space. If done well, this approach can be very effective.

You must cache properly. If the wrong data is cached, the storage space is wasted. If you cache too much, there will be very little memory available for other operations. If you cache too little, the efficiency will be low because you have to recalculate the missing data. If time-sensitive data is cached for too long, the data will be out of date. In general, servers are more concerned with speed than space, so they have more cache than desktop systems. Be sure to remove unused caches on a regular basis, otherwise there will be problems with running settings.

4. Multiple threads should be created, the more the better.

It is important to adjust the number of threads that work in the server. If the thread is I/O-bound, it will take a lot of time to wait for the completion of the I/O - a blocked thread is a thread that does not do any useful work. Adding extra threads can increase throughput, but adding too many threads will degrade server performance because context swapping will be a significant overhead. There are three reasons why the context exchange speed should be low: context swapping is pure overhead, and there is no benefit to the application's work; context swapping runs out of valuable clock cycles; worst of all, context swap fills the processor's cache For useless data, replacing this data is costly.

There are many things that depend on your threaded structure. One thread per client is absolutely inappropriate. Because it is not scalable for a large number of clients. Contextual exchanges become unbearable, and Windows NT runs out of resources. The thread pool model will work better, in which a worker thread pool will process a request column because Windows 2000 provides the corresponding APIs, such as QueueUserWorkItem.