Server | Performance not to be measured
When you can measure what you are talking about and use numbers to express it, this means that you have a certain understanding of him, but if you can not use digital expression, your knowledge is poor and unsatisfactory; this may be the beginning of knowledge, but it is impossible for you to raise your mind to the level of science.
-Lord Kelvin (William Thomson)
You cannot understand the characteristics of an application without measuring it. You grope in the dark, half by guessing. If you do not recognize performance issues, you cannot make any improvements or make a workload plan.
Measurements include black box measurements and profiling. The black box measurement means collecting data displayed by performance counters (memory usage, context Exchange, CPU utilization, etc.) and external instrumentation (flux, reflection time, etc.). To profile your code, you compile a tool version of the code, run it under various conditions, and collect statistics about the execution time and the frequency of the process call.
Measurement is not useful if it is not used for analysis. Measurement will not only tell you there is a problem, but it can even help you find out where the problem is, but it can't tell you why there is a problem. Analyze the problem so that you can correct them correctly. To fundamentally solve the problem rather than stay on the surface of the phenomenon.
When you make changes, you need to measure again. You need to know if your changes are valid. Changes may also expose other performance issues, and the measurement-analysis-correction-and-measurement cycle will start over. You also have to do a regular measurement to find out the problem of performance degradation.
You should use a single user, a single request test method.
One common problem with writing ASP and ISAPI applications is to test the application with only one browser. When they apply their programs on the Internet, they find that their applications cannot handle the high load, and that the flux and response times are pathetic.
Testing with a browser is necessary but not enough. If the browser doesn't react fast enough, you'll know you're in trouble. But even if it's quick to use a browser, you don't know how it can handle the load. What happens if more than 10 users request it at the same time? What about 100? What kind of flux can your application tolerate? What kind of reaction time does it provide? What will these numbers be like in light load? What about the medium load? What about overloading? What happens to your application on a multiprocessor machine? The strength test for your application is fundamental to finding the bugs discovery performance problem.
Similar load test considerations apply to all server applications.
The actual environment should not be used.
People tend to adjust applications only in a few specific, artificial environments (below benchmarks). It is important to select the various situations that correspond to the actual situation and to optimize for the various operations. If you don't, your users and reviewers will do it, and they'll judge your application for good or bad.
Conclusion
Since we started to develop IIS, we have a certain understanding of stifling server performance and scalability. It is not easy to write High-performance server applications. In addition to the traditional issues encountered in writing desktop applications, you must pay special attention to memory allocations, cache columns, cached data, threading prototyping, locking strategies, multiprocessor machines, modular invocations, measurement and analysis, multiuser testing, and real-world problems. These problems can make you and possibly ruin you.
