Server | Performance should use global locks on data structures
The easiest way to make data thread safe is to put it on a large lock. For the sake of simplicity, all things are locked with the same lock. There is a problem with this approach: serialization. In order to get a lock, each thread that handles data must be queued. If the thread is blocked by a lock, it is not doing anything useful. This problem is not common when the server is lighter, because only one thread at a time may require a lock. In heavy loads, a fierce scramble for locks could be a big problem.
Imagine an accident on a multiple-lane highway where all the vehicles on the freeway were diverted to a narrow road. If there are few vehicles, the effect of this conversion on the rate of traffic flow can be ignored. If there are many vehicles, traffic jams can stretch for several miles when the vehicle is slowly merged into the single channel.
There are several technologies that can reduce lock competition.
· Don't be overly protective, that is to say, it is not necessary not to lock the data. Only need to hold the lock, and time not too long. It is important not to use locks unnecessarily in code around large pieces of code or frequently executed.
· The data is segmented so that it can be protected with a single set of locks. For example, a symbol table can be separated by the first letter of the identifier, so that when you modify the value of a symbol whose first name begins with Q, you do not read the value of the symbol whose name begins with H.
· Use the APIs ' interlocked series (interlockedincrement,interlockedcompareexchangepointer, etc.) to automatically modify the data without the need for a lock.
· Multiple reader/single author (multi-reader/single-writer) locks can be used when data is not often modified. You will get better concurrency, even though the cost of the lock operation will be higher and you may risk starving the author.
· Use the loop counter in the critical section. See the Setcriticalsectionspincount API in Windows NT 4.0 Service Pack 3.
· If you can't get the lock, use tryentercriticalsection and do some other useful work.
High competition causes Serialization,serialization to reduce CPU utilization, prompting users to add more threads, and things get worse.
No need to pay attention to multiprocessor machines
It may be disgusting that your code runs worse on multiprocessor systems than it does on a single-processor system. A natural idea is that it would be better to run N times on an n-dimensional system. Poor performance is due to competition: Lock competition, bus competition, and/or cache column competition. Processors are competing for ownership of shared resources, rather than doing more work.
If you have to write multithreaded applications, you should test your application for strength and performance on a multiprocessor box. Single-processor systems provide an illusion of concurrency by executing threads over time. Multi-processor boxes have real concurrency, and competitive environments and competition are more likely to occur.
Modular calls should always be used; they're interesting.
Using synchronous modulation to perform I/O operations is appropriate for most desktop applications. However, they are not a good way to use the CPU (s) on the server. I/O operations take millions of clock cycles to complete, and these clock cycles could have been better utilized. With asynchronous I/O you can get a significantly higher user request rate and I/O flux, but add additional complexity.
If you have a modular call or I/O operation that takes a long time, you should test how much resources to allocate to them. Do you want to use all threads or is there a limit? Generally, it is better to use a limited number of threads. Build a small thread pool and queues, using queues to arrange the work of the threads to complete the modular call. This way, other threads can pick up and process your non modular request.
