There are four key performance metrics that most of you are interested in as you develop your XML-based web application:
· Working set: The peak amount of memory used by MSXML to process requests. Once the working set exceeds available RAM, performance usually declines shARPly as the operating system starts paging memory out to disk.
· Megabytes per second: Simply a measure of raw speed for a given operation, such as the document load method. By itself it is interesting, but to get the real picture for a production application, you really need to consider the next two metrics as well.
· Requests per second: A measure of how many requests the XML parser can handle per second. An XML parser might have a high megabytes-per-second rate, but if it is expensive to set up and tear down that parser, it will still have a low throughput in requests per second. This metric can help you calculate how many clients your server can handle under a peak load. Obviously, this depends on how heavily the clients are going to load up your server. For example, if the clients hit the server at a peak rate of one request per second, and if the server can do 150 requests per second, the server can probably handle up to 150 clients.
· Scaling: A measure of how well your server can process requests in parallel. If your server is processing 150 client requests in parallel, then it is doing a lot of multi-threading. Processing 150 threads in parallel is rather much for one processor, which will spend a lot of time just switching between these threads. In this scenario, you might add more processors to the computer to share the load.
For example, a quad-processor server would need to process only 37 threads per processor—a more reasonable amount. (Scaling beyond this can be done with Web farms.) The goal is to scale linearly with the number of processors you add (for example, a quad-processor server should be four times faster than a single-processor computer). However, this is rarely achieved because there is usually some sort of contention for shared resources, such as memory, file system, registry, and.NETwork. Most components also contend for their own internal shared resources (for example, a global state that is protected by locks). Typically, when you add processors, scaling problems become a lot more obvious. For more information on scaling up and scaling out, see the ASP">Duwamish Diary column.
例如，对于一个四处理器的服务器，每个处理器只需要处理37个线程了，这是更合理的数量。（Web farm可以用来处理更高层次的伸缩性。）我们的目的是使得增加的处理器数量与性能的提高成正比（例如，一个四处理器的服务器应该比单处理器的计算机要快四倍）。但是，这通常是做不到的，因为还有很多类型的内容要共享，如内存，文件系统，注册表和网络。大部分组件还要竞争一些内部的共享资源（例如，一个全局状态被锁保护了）。通常，当你增加处理器时，伸缩性问题变得明显起来。想要得到更多伸缩性方面的资料，请查阅Duwamish Diary的专栏文章。
Disclaimer: I want you to understand that the numbers published here are not official in any way, but are intended to paint the overall picture so that you can get a feel for what kinds of things to expect and be able to make the right design choices while building your XML applications.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752043/viewspace-991658/，如需转载，请注明出处，否则将追究法律责任。