Inside MSXML Performance(MSXML效能分析) （2） (轉)

Inside MSXML Performance(MSXML效能分析) （2） (轉)[@more@]

Metrics:namespace prefix = o ns = "urn:schemas--com::office" />

度量指標

There are four key performance metrics that most of you are interested in as you develop your XML-based 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 shly 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 consr 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 res, such as memory, file system, registry, andwork. 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 ">Duwamish Diary column.

例如，對於一個四處理器的伺服器，每個處理器只需要處理37個執行緒了，這是更合理的數量。（Web farm可以用來處理更高層次的伸縮性。）我們的目的是使得增加的處理器數量與效能的提高成正比（例如，一個四處理器的伺服器應該比單處理器的要快四倍）。但是，這通常是做不到的，因為還有很多型別的內容要共享，如記憶體，檔案系統，登錄檔和。大部分還要競爭一些內部的共享資源（例如，一個全域性狀態被鎖保護了）。通常，當你增加處理器時，伸縮性問題變得明顯起來。想要得到更多伸縮性方面的資料，請查閱的專欄文章。

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應用程式時你必須考慮哪些事情，結果會怎樣，應該做怎樣的設計選擇。