Inside MSXML Performance(MSXML性能分析) （2） (转)

Inside MSXML Performance(MSXML性能分析) （2） (转)[@more@]

MetricsXML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />

度量指标

There are four key performance metrics that most of you are interested in as you develop your XML-based web application:

当开发基于XML的Web应用程序时，大部分人对以下四个主要的性能度量指标感兴趣：

·  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.

·  工作集（Work set）：MSXML处理请求的峰值内存空间。一旦处理空间超过了可用的RAM，操作系统将页面调度到磁盘，性能通常会急剧下降。

·  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.

·  百兆字节每秒：简单衡量一给定的操作（如文件load方法）的速度。但是在实际应用中，你还需要考虑以下两个衡量标准。

·  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.

·  每秒处理的请求数：用来表示XML解析器每秒可处理的请求数。一个XML解析器可能每秒处理的百兆字节量很高，但是如果初始化和关闭该解析器的代价很大，那么它的每秒处理请求数仍旧很低。这个度量指标可以帮助你计算在峰值负载下，服务器能够接受多少客户。显然，这取决于客户端访问服务器的频率。例如，如果每个客户端点击服务器的峰值是每秒一个请求，而服务器能够在一秒钟内处理150个请求，那么服务器就能够同时处理150个客户。

·  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.

·  伸缩性：这是用来表示服务器并行处理请求的能力。如果你的服务器能够并行处理150个客户端请求，那么它会同时处理很多线程。并行处理150个线程对于一个处理器来说负担很大，大部分时间都消耗在线程切换上。在这种情况下，你必须增加更多的处理器来分担负荷。

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.

声明：我想让你们理解，这里发表的数据并不是官方正式的，只是用来让你们有个全局的感觉：当建立XML应用程序时你必须考虑哪些事情，结果会怎样，应该做怎样的设计选择。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752043/viewspace-991658/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10752043/viewspace-991658/