1. 利用Windows自帶的性能監視器對WebService服務進行監控，通常使用哪些計數器，標准值是什麼
1. 處理器對象(Processor Object)
2. 系統對象(System Object)
3. SQL Server：緩沖區管理器對象( B u ffer Manager Object)
4. SQL Server：資料庫對象(Database Object)
5. SQL Server：常規統計對象(General Statistics Object)
6. SQL Server：閂對象(Latches Object)
7. SQL Server：鎖對象(Locks Object)
8. SQL Server：內存管理器對象(Memory Manager Object)
9. SQL Server：S Q L統計對象(SQL Statistics Object)
10. 邏輯磁碟對象(Logical Disk Object)
11. 物理磁碟對象(PhysicalDisk Object)
12. 內存
一條經驗規則是不要使你所監控的每個處理器的C P U使用率高於9 0％。峰值超過9 0％是可以接受的，但平均使用率超過9 0％則是應該避免的。
• 處理器時間百分比(％Processor Time) 處理器執行一個非空閑線程的時間百分比。用％1 0 0減去處理器空閑的總時間得出這個值。這是整個系統的C P U使用的一個好的指示器。
• 特權時間百分比(％Privileged Time) 處理器用於在特權模式下(即，執行操作系統功能和運行驅動器，如I / O )工作時間的百分比。這個時間包括C P U (或C P U )用於維護中斷和延遲過程調用( D P C )的時間。
• 用戶時間百分比(％User Time) 處理器用於在用戶模式工作的時間百分比。這種類型的工作是由應用產生的。通常，希望極大化用戶時間百分比的值，極小化特權時間百分比的值。
• 中斷時間百分比(％Interrupt Time) CPU忙於維護硬體中斷的時間百分比。系統中的許多硬體部件，如滑鼠、網路介面卡或磁碟控制器，都可以發出處理器中斷。你可以將中斷看作為Windows NT正常操作的一部分發生。
• 中斷數/秒(Interrupts/sec) 處理器每秒接收並處理的硬體中斷的數量。它不包括系統
D P C，系統D P C單獨計數。
系統對象與它的相關計數器衡量處理器上運行的線程的總計數據。雖然使用這些計數器不能觀察一個特定處理器的工作負載或一個特定線程的行為，但它們提供了有關整個系統性能有價值的內部信息。系統計數器如下所示：
• 處理器隊列長度(Processor Queue Length) 處理器隊列中的線程的數量。換句話說，它
是等待運行的線程數。即使你的系統具有多個處理器，但只有一個隊列用於處理器時間。計數器只記錄那些准備執行但仍處於等待的線程，不是那些正在運行的線程。
• 環境切換/秒(Context Switches/sec) 系統上的所有處理器從一個線程切換到另一個線程的組合比率。當一個正在運行的線程自動地放棄處理器，處理器由一個高優先順序的待命線程搶占時發生環境切換，或在用戶模式和特權(核心)模式之間切換，以使用一個執行或子系統的服務。這是線程的總和：計算機上運行在所有處理器上的所有線程的環境切換數/秒。
緩沖區管理器計數器提供了SQL Server使用的內存緩沖區的有關信息。這些計數器如下所示：
• 高速緩存命中率( B u ffer Cache Hit Ratio) 引用當前位於高速緩存中頁的需求的百分率。預先在內存中擁有頁，允許SQL Server避免請求從磁碟子系統執行一次物理I / O。因為訪問內存相對於訪問物理I / O，代價更小，一個高的緩沖區高速緩存命中率增強了系統的性能與吞吐量。如果你的系統很好地調整過，這個命中率應該是8 0％或更高。如果具有一個低的緩沖區高速緩存命中率，你應該為SQL Server分配更多的內存。如果你已將現有的所有內存都分配給了SQL Server，那麼需要增加系統中物理內存的數量。
• 高速緩存大小(頁)(Cache Size) 在SQL Server緩沖區高速緩存中的頁的數量。這個數量乘以8 K B，即可得到正在使用的以千位元組為單位的緩存數。
• 空閑緩沖區(Free Buffer) 空閑SQL Server內存緩沖區的數量。
• 讀的頁/秒(Page Reads/sec) 每秒請求的物理數據頁I / O的數量。
• 偷取的頁計數(Stolen Page Count) SQL Server用於緩沖區高速緩存的頁數，這些內存被給予系統中的另外一個進程。Windows NT回收這個內存以滿足其他系統部件的需要。
• 寫的頁/秒(Page Writes/sec) 由SQL Server執行的每秒寫的物理數據頁的數量。
資料庫對象計數器提供了有關SQL Server資料庫的信息，包括可用的空閑日誌空間量和資料庫中活動事務的數量。對於系統中的每個資料庫的每個計數器有一個實例。這些計數器包括如下：
• 日誌刷新等待/秒(Log Flush Wait/sec) 在能夠繼續執行前，必須等待日誌刷新的資料庫提交數量。
• 日誌使用的百分比(Percent Log Used) SQL Server實際使用的當前定義的日誌空間的百分比。
常規統計對象含有常規伺服器范圍活動的有關信息，它有一個計數器：
• 用戶連接數(User Connections) 系統中用戶連接的當前數量。
這個對象計數器提供了在內部SQL Server資源中有效的閂的信息。計數器如下：
• 平均閂等待時間(毫秒) ( Average Latch Wait Time) 閂請求在得到服務之前必須等待的平均時間，以毫秒為單位。
• 閂等待數/秒(Latch Waits/sec) 不能立即服務，被迫等待其他資源釋放的閂請求的數量。
鎖對象提供了由SQL Server提出的各個鎖請求的有關數據，例如鎖生命周期和死鎖。可以在系統上具有多個這些計數器的實例。計數器如下所示：
• 平均等待時間(毫秒) ( Average Wait Time) 每個鎖請求被迫等待的平均時間量，以毫秒為單位。
• 鎖到期數/秒(Lock Timeouts/sec) 在系統中過期的鎖請求的數量。
• 鎖等待數/秒(Lock Wa i t s / s e c )不能立即滿足，需要調用線程在給予鎖之前處於等待狀態的鎖請求的數量。
• 死鎖數/秒(Number of Deadlocks/sec) 導致產生死鎖的鎖請求的數量。
內存管理器對象含有有關SQL Server內存使用的信息，包括SQL Server正在使用的高速緩
存內存的數量。這個對象下的計數器如下所示：
• 內存授權掛起(Memory Grants Pending) 等待授予工作空間內存的進程的當前數量。
• S Q L高速緩存內存(KB)(SQL Cache Memory) SQL Server用於動態SQL 高速緩存的動態
內存數量。
• 目標伺服器內存( K B ) ( Ta rget Server Memory) SQL Server將會消耗的動態內存的總額。
• 總的伺服器內存( K B ) ( Total Server Memory) SQL Server當前消耗的動態內存的總額。
這個對象提供了系統上正在執行的S Q L查詢的有關信息，包括查詢編譯和重新編譯的數量的數據。它有如下計數器：
• 批請求/秒(Batch Requests/sec) 伺服器接收到的S Q L批請求的數量。
• SQL 編譯/秒(SQL Compilations/sec) SQL Server每秒執行的S Q L語句編譯的數量。
• S Q L重新編譯/秒(SQL Re-Compilations/sec) SQL Server每秒執行的S Q L語句重新編譯的數量。
邏輯磁碟對象提供了有關邏輯磁碟I / O性能的信息。邏輯磁碟計數器與Windows NT磁碟
系統管理員分配給邏輯磁碟驅動器的字母相關。這個對象含有如下計數器：
• 磁碟讀時間百分比(％Disk Read Time) 選中的邏輯磁碟忙於服務讀請求總共用去時間的
百分比。
• 磁碟寫時間百分比(％Disk Write Time) 選中的邏輯磁碟忙於服務寫請求總共用去時間
的百分比。
• 磁碟時間百分比(％Disk Time) 選中的邏輯磁碟忙於服務讀請求或寫請求總共用的時間
的百分比，是磁碟寫時間百分比與磁碟讀時間百分比的和。
• 空閑時間百分比(％Idle Time) 邏輯磁碟在采樣時間間隔中處於空閑狀態的時間百分比。
• 平均磁碟隊列長度( Avg. Disk Queue Length) 在采樣的時間間隔中，選中的邏輯磁碟讀請求和寫請求排隊的平均數量。
• 平均磁碟讀隊列長度( Avg. Disk Read Queue Length) 在采樣的時間間隔中，對選中的邏輯磁碟讀請求排隊的平均數量。
• 平均磁碟寫隊列長度( Avg. Disk Write Queue Length) 在采樣的時間間隔中，對選中的邏輯磁碟寫請求排隊的平均數量。
• 平均磁碟秒數/讀( Avg. Disk sec/Read) 從邏輯磁碟讀數據的平均時間，以秒為單位。
• 平均磁碟秒數/寫( Avg. Disk sec/Write) 向邏輯磁碟寫數據的平均時間，以秒為單位。
• 平均磁碟秒數/傳輸( ( Avg. Disk sec/Transfer) 從邏輯磁碟進行傳輸的平均時間，以秒為單位。
• 磁碟讀/秒(Disk Reads Bytes/sec) 邏輯磁碟上每秒讀位元組。
• 磁碟讀/秒(Disk Writes Bytes/sec) 邏輯磁碟上每秒寫位元組。
• 磁碟讀/秒(Disk Reads/sec) 邏輯磁碟上的讀操作比率。
• 磁碟寫/秒(Disk Writes/sec) 邏輯磁碟上的寫操作比率。
• 磁碟傳輸/秒(Disk Transfers/sec) 邏輯磁碟上的讀和寫操作的比率。
物理磁碟對象提供了有關物理磁碟I / O性能的信息。它的磁碟計數器與系統中的物理驅動器有關，並且只有當運行了D i s k P e r f服務時，它才被激活。這個對象下的計數器如下所示：
• 磁碟讀時間百分比(％Disk Read Time) 選中的物理磁碟忙於服務讀請求總共用的時間的百分比。
• 磁碟寫時間百分比(％Disk Write Time) 選中的物理磁碟忙於服務寫請求總共用的時間的百分比。
• 磁碟時間百分比(％Disk Time) 選中的物理磁碟忙於服務讀請求或寫請求總共用的時間的百分比，是磁碟寫時間百分比與磁碟讀時間百分比的和。
• 空閑時間百分比(％Idle Time) 物理磁碟在采樣時間間隔中處於空閑狀態的時間百分比。
• 平均磁碟隊列長度( Avg. Disk Queue Length) 在采樣的時間間隔中，選中的物理磁碟讀請求和寫請求排隊的平均數量。
• 平均磁碟讀隊列長度( Avg. Disk Read Queue Length) 在采樣的時間間隔中，選中的物理磁碟讀請求排隊的平均數量。
• 平均磁碟寫隊列長度( Avg. Disk Write Queue Length) 在采樣的時間間隔中，選中的物理磁碟寫請求排隊的平均數量。
• 平均磁碟秒數/讀( Avg. Disk sec/Read) 從物理磁碟讀數據的平均時間，以秒為單位。
• 平均磁碟秒數/寫( Avg. Disk sec/Write) 向物理磁碟寫數據的平均時間，以秒為單位。
• 平均磁碟秒數/傳輸( Avg. Disk sec/Transfer) 從物理磁碟進行傳輸的平均時間，以秒為單位。
• 磁碟讀/秒(Disk Reads Bytes/sec) 物理磁碟上每秒讀位元組。
• 磁碟讀/秒(Disk Writes Bytes/sec) 物理磁碟上每秒寫位元組。
• 磁碟讀/秒(Disk Reads/sec) 物理磁碟上的讀操作比率。
• 磁碟寫/秒(Disk Writes/sec) 物理磁碟上的寫操作比率。
• 磁碟傳輸/秒(Disk Transfers/sec) 物理磁碟上的讀和寫操作的比率。
內存在任何系統中都是一個非常有價值的資源。Windows NT不只允許過量使用內存，而且鼓勵你過量使用內存。Windows NT提供了一種透明機制，允許應用「相信」它們具有比系統中可用的物理內存更多的內存。當Windows NT處理應用時，它將不使用的內存頁調出(交換出)到磁碟上的頁文件中。在大多數系統中，頁調度是正常的，但過量的頁調度會削弱整個系統的性能。下面的計數器允許你監控系統的頁調度。
• 失效的頁/秒(Page Faults/sec) 每秒由處理器處理的失效頁的全部數量。當一個進程需
要的代碼或數據不在它的工作區(它的空間在物理內存中)中時，發生失效頁。這個計數
器包括硬的頁失效(那些需要磁碟訪問的)和軟的頁失效(在物理內存的其他地方發現了失
效頁)。
• 讀的頁/秒(Page Reads/sec) 讀取磁碟以解決硬的頁失效所需要的時間數(當一個進程需要的代碼或數據不在其工作區或內存中的其他地方，必須從磁碟提取這些代碼和數據時，發生硬的頁失效)。這個計數器包括為滿足在文件系統高速緩存(通常是應用請求的)以及在非高速緩存映像內存文件中的失效而進行的讀。
• 寫的頁/秒(Page Writes/sec) 將頁寫向磁碟以釋放物理內存空間的時間數。只有當頁在物理內存中被改變的時候，將頁寫入磁碟，這樣，它們更有可能含有數據，而不是代碼。
• 頁/秒(Pages/sec) 為解決硬的頁失效，所需要讀或寫磁碟的時間數。它是讀的頁/秒與寫的頁/秒的計數器的和。
2. windows自帶性能監控器問題
你要滴在任務管理器里全部都有 ALT +DEL+ CTRL
Windows 性能監視器工具
如果需要在一台計算機上監視多個 Report Server 實例，可以同時或單獨監視這些實例。選擇要包括的實例是計數器添加過程的一部分。有關使用 Windows 附帶的性能工具的更多信息，請參見微軟 Windows 產品文檔。
若要訪問性能工具
• 從「開始」菜單上選擇「運行」。
• 在「打開」文本框中輸入「perfmon」，然後單擊「確定」。
• 在性能監視器工具中，在左側窗格里選擇 System Monitor 對象，然後右擊「性能」圖表。
• 選擇「添加計數器」。
現在，可以開始選擇這些對象和要監視的計數器了。
ASP.NET 應用程序性能計數器
有關 ASP.NET 應用程序性能計數器的大部分信息最近已被合並到一個題為「改善 .NET 應用程序的性能和伸縮性」的綜合文檔中。下表描述了一些可用於監視和優化 ASP.NET 應用程序（包括 Reporting Services）性能的重要計數器。
性能對象 計數器 實例 描述
Processor（處理器）
% Processor Time（處理器時間百分比）
__Total
「% Processor Time」監視運行 Web 伺服器的計算機的 CPU 利用率。低 CPU 利用率或者無法最大化 CPU 利用率（無論客戶端負載為多少）都表明 Web 應用程序中存在對資源的爭用或鎖定。
Process（進程）
% Processor Time（處理器時間百分比）
aspnet_wp 或 w3wp（具體情況視 IIS 版本而定）
由 ASP.NET 工作進程所使用的處理器時間所佔的百分比。在將標准負載情況下的性能與先前捕獲的基準進行對比時，如果此計數器的值出現下降，則說明降低了對處理器的需求，因此也提高了伸縮性。
Process（進程）
Working Set（工作集）
aspnet_wp 或 w3wp（具體情況視 IIS 版本而定）
由 ASP.NET 主動使用的內存數量。雖然應用程序開發人員對應用程序使用的內存數量擁有最大的控制權，但系統管理員也可通過調整會話的超時期限來顯著影響這一點。
Process（進程）
Private Bytes（專有位元組）
aspnet_wp 或 w3wp（具體情況視 IIS 版本而定）
Private Bytes 是當前分配給該進程且不能由其他進程共享的內存數量（以位元組計）。不時出現的尖峰表明某些地方存在瓶頸，會導致工作進程繼續持有不再需要的內存。如果此計數器突然下降為接近 0 的值，則可能表示 ASP.NET 應用程序由於無法預料的問題進行了重啟。為了驗證這一點，請監視「ASP.NET Application Restarts」計數器。
ASP.NET Applications（ASP.NET 應用程序）
Requests/ Sec（每秒的請求數）
__Total
允許您檢驗請求的處理速度是否於發送速度相適應。如果每秒請求數的數值低於每秒產生的請求數，則會出現排隊現象。這通常意味著已經超過了最大請求速度。
ASP.NET Applications（ASP.NET 應用程序）
Errors Total（總錯誤數）
__Total
在執行 HTTP 請求期間發生的錯誤總數。包括任何分析器、編譯或運行時錯誤。此計數器是「Errors During Compilation」（編譯錯誤數）、「Errors During Preprocessing」（預處理錯誤數）和「Errors During Execution」（執行錯誤數）計數器的總和。運轉正常的 Web 伺服器不應產生任何錯誤。如果錯誤發生在 ASP.NET Web 應用程序中，它們的存在可能會讓實際的吞吐量結果產生偏差。
ASP.NET
Request Execution Time（請求執行時間）
顯示了呈現所請求頁面並將其傳送給用戶所需的時間（以毫秒計）。跟蹤此計數器通常要比跟蹤頁面呈現時間效果更好。此計數器可以更全面地衡量從開始到結束的整個請求時間。在與基準進行對比時，如果此計數器的平均值較低，則說明應用程序的伸縮性和性能均得到了改善。
ASP.NET
Application Restarts（應用程序重新啟動）
應用程序在 Web 伺服器生存期間發生重新啟動的次數。每次發生 Application_OnEnd 事件時，應用程序的重新啟動次數都會增加。應用程序進行重新啟動的原因可能是：更改了 Web.config 文件、更改了存儲在應用程序的 \bin 目錄下的程序集、或者 Web Forms 頁面中發生了太多的更改。如果此計數器的值出現意料之外的增加，說明某些不可預知的問題導致 Web 應用程序被關閉。在這種情況下，應該認真調查問題原因。
ASP.NET
Requests Queued（排隊的請求數）
在隊列中等待服務的請求數。如果此數字隨著客戶端負載的增加而呈現線性的增長，則說明 Web 伺服器計算機已經達到了它能夠處理的並發請求極限。此計數器的默認最大值為 5,000。您可以在計算機的 Machine.config 文件中更改此設置。
ASP.NET
Worker Process Restarts（工作進程重新啟動）
工作進程在伺服器計算機上重新啟動的次數。如果出現意料之外的故障或者被有意回收，則工作進程會重新啟動。如果此計數器的值出現意料之外的增加，應認真調查問題原因。
除了上表中介紹的這些核心監視要素之外，在您試圖診斷 ASP.NET 應用程序具有的特定性能問題時，下表中的性能計數器也可對您有所幫助。
性能對象 計數器 實例 描述
ASP.NET Applications（ASP.NET 應用程序）
Pipeline Instance Count（管線實例計數）
__Total
指定 ASP.NET 應用程序的活動請求管線實例的數量。由於只有一個執行線程可以在管線實例內運行，所以此數值反映了為特定應用程序處理的並發請求的最大數量。大多數情況下，在存在負載的情況下此數值較低為佳，這表明處理器得到了很好的利用。
.NET CLR Exceptions（.NET CLR 異常）
# of Exceps Thrown（引發的異常數）
顯示應用程序中引發的異常數。如果此數值出現意料之外的增加，說明可能存在性能問題。如果僅僅存在異常，則並不需要擔心，因為異常對於某些代碼路徑來說是正常工作的一部分。例如，HttpResponse.Redirect 方法通過引發一個不可捕獲的異常 ThreadAbortException 來完成工作。同樣，對 ASP.NET 應用程序跟蹤此計數器也更加有用。使用「Errors Total」計數器確定該異常是否將導致應用程序出現意料之外的錯誤。
System（系統）
Context Switches/ sec（每秒的上下文切換次數）
測量 Web 伺服器計算機上所有處理器切換線程上下文的速度。如果此計數器的值很高，可能表示對鎖的爭用頻繁發生，或者在線程的用戶模式和內核模式之間切換頻繁。使用采樣優化程序和其他工具執行進一步調查可證實上述猜測。
Reporting Services 性能計數器
Reporting Services 包括一組它自己的性能計數器，用於收集有關報告處理和資源消耗方面的信息。可通過 Windows 性能監視器工具中出現的兩個對象來監視實例和組件的狀態和活動：MSRS 2005 Web Service 和 MSRS 2005 Windows Service 對象。
MSRS 2005 Web Service 性能對象包括一組用來跟蹤 Report Server 處理過程的計數器，這些處理過程通常通過在線互動式報告瀏覽操作而引發。這些計數器在 ASP.NET 停止該 Web 服務後被重設。下表列出了可用於監視 Report Server 性能的計數器，並描述了它們的目的。
性能對象：RS Web Service
計數器 描述
Active Sessions（活動會話數）
活動會話的數量。此計數器反映了尚未過期的所有瀏覽器會話總數。這並不是同時處理的請求數，而是存儲在 ReportServerTempDB 資料庫中的會話數量。
Cache Hits/Sec（每秒緩存命中次數）
每秒從目錄中取得的報告請求的數量。如果此值增加，而「Memory Cache Hits」的值不增加，則說明報告數據沒有被重新處理，但是頁面被重新呈現。將此計數器與 Memory Cache Hits/Sec 計數器一同使用，可以確定用於緩存、磁碟或內存的資源是否充足。
Cache Misses/Sec（每秒緩存未命中數）
每秒未能從目錄中（與內存中相對）返回報告的請求數量。將此計數器與 Memory Cache Misses/Sec 計數器一同使用，可以確定用於緩存、磁碟或內存的資源是否充足。
First Session Requests/Sec（每秒的首次會話請求數）
每秒中從 Report Server 緩存中啟動的新的用戶會話數量。
Memory Cache Hits/Sec（每秒內存緩存命中數）
每秒中從內存中的緩存里取得報告的次數。內存中緩存是 Reporting Services 緩存的一部分，用於在內存或臨時文件中保存已呈現過的報告。這樣可以為請求提供最佳的性能，因為無需執行任何處理工作。如果使用內存中緩存，報告伺服器將不會通過查詢 SQL Server 來獲得緩存的內容。
Memory Cache Misses/Sec（每秒內存緩存未命中數）
每秒中未能從內存中的緩存里取得報告的次數。
Next Session Requests/Sec（每秒的下一次會話請求）
每秒在現有會話中請求打開報告的次數。
Report Requests（報告請求）
當前處於活動狀態並且將由 Report Server 進行處理的報告數量。
Reports Executed/Sec（每秒執行的報告數）
每秒成功執行的報告的數量。此計數器提供了有關報告處理量的統計信息。綜合使用此計數器和 Request/Sec，比較可從緩存中返回的報告請求的執行情況。
Requests/Sec（每秒的請求數）
每秒向 Report Server 發出的請求數。此計數器跟蹤由 Report Server 處理的所有類型的請求。
Total Cache Hits（緩存命中總數）
自服務啟動以來，從緩存中獲得報告的請求總數。此計數器在 ASP.NET 停止該 Web 服務後被重設。
Total Cache Misses（總的緩存未命中數）
自服務啟動以來，不能從緩存中獲得報告的總次數。此計數器在 ASP.NET 停止該 Web 服務後被重設。可使用此計數器確定磁碟空間和內存是否充足。
Total Memory Cache Hits（總的內存緩存命中數）
自服務啟動以來，從內存中緩存里返回的已緩存報告的總數。此計數器在 ASP.NET 停止該 Web 服務後被重設。內存中緩存是在 CPU 內存中存儲報告的那部分緩存。如果使用內存中緩存，報告伺服器將不會通過查詢 SQL Server 來獲得緩存的內容。
Total Memory Cache Misses（總的緩存未命中數）
自服務啟動以來，針對內存中緩存的緩存未命中總數。此計數器在 ASP.NET 停止該 Web 服務後被重設。
Total Processing Failures（處理故障總數）
自服務啟動以來，發生的所有報告處理故障的總數。此計數器在 ASP.NET 停止該 Web 服務後被重設。處理故障可能來自報告處理器，也可能來自任何擴展。
Total Reports Executed（執行的報告總數）
自服務啟動以來得到成功執行的報告的總數。
Total Requests（總請求數）
自服務啟動以來，向 Report Server 發送的所有請求的總數。
RS Windows Service 性能對象包括一組用於跟蹤報告處理過程的計數器，這些處理過程是通過預定操作而引發的。預定操作可能包括訂閱和交付、報告執行快照以及報告歷史。微軟的工作負載中並不包含任何預定操作或交付操作，此處列出這些性能計數器僅是便於您進行參考。
可使用此性能對象監視 Report Server Windows 服務。如果您准備在一個橫向伸縮配置中運行 Report Server，那麼這些計數器應用於所選的伺服器，而不是應用於橫向伸縮配置整體。這些計數器在應用程序域回收之時將被重設。下表列出了可用於監視預定和交付操作的計數器，並描述了它們的目的。
性能對象：RS Windows Service
計數器 描述
Cache Flushes/Sec(每秒緩存刷新次數)
每秒刷新緩存的次數。
Cache Hits/Sec（每秒緩存命中數）
每秒獲取到緩存報告的請求數量。
Cache Misses/Sec（每秒緩存未命中數）
每秒未能從緩存中獲得報告的請求的數量。
Delivers/Sec（每秒交付數）
每秒從各種交付擴展交付的報告的數量。
Events/Sec（每秒事件數）
每秒處理的事件數量。被監視的事件，包括 SnapshotUpdated 和 TimedSubscription。
Memory Cache Hits/Sec（每秒內存緩存命中數）
每秒中從內存中的緩存里取得報告的次數。
Memory Cache Misses/Sec（每秒內存緩存未命中數）
每秒中未能從內存中的緩存里取得報告的次數。
Report Requests（報告請求數）
當前處於活動狀態並且將由 Report Server 進行處理的報告數量。可使用此計數器評估緩存策略。向特定呈現擴展提交的請求數。請求的數量可能比執行的報告數量多許多。
Reports Executed/Sec（每秒執行的報告數）
每秒成功執行的報告的數量。
Snapshot Updates/Sec（每秒快照更新數）
每秒報告執行快照的預定更新數量。
Total App Domain Recycles（應用程序域回收總數）
自服務啟動以來回收的應用程序域總數。
Total Cache Flushes（緩存刷新總數）
自服務啟動以來，Report Server 的緩存更新總數。
Total Cache Hits（緩存命中總數）
自服務啟動以來，從緩存中獲得報告的請求總數。
Total Cache Misses（總的緩存未命中數）
自服務啟動以來，不能從緩存中獲得報告的總次數。
可使用此計數器確定是否需要更多磁碟空間或內存。
Total Deliveries（總交付數）
由 Scheling and Delivery Processor 交付的報告總數（對於所有交付擴展）。
Total Events（總事件數）
自服務啟動以來發生的事件的總數。
Total Memory Cache Hits（總的內存緩存命中數）
自服務啟動以來，從內存中緩存里返回的已緩存報告的總數。
Total Memory Cache Misses（總的緩存未命中數）
自服務啟動以來，針對內存中緩存的緩存未命中總數。
Total Processing Failures（處理故障總數）
自服務啟動以來，發生的所有報告處理故障的總數。處理故障可能來自報告處理器，也可能來自任何擴展。
Total Rejected Threads（被拒絕的線程總數）
拒絕執行非同步處理後在同一線程中作為同步過程在以後進行處理的數據處理線程總數。
Total Report Executions（報告執行總數）
已執行報告的總數。
Total Requests（請求總數）
自服務啟動以來得到成功執行的報告的總數。
Total Snapshot Updates（快照更新總數）
自服務啟動以來，報告執行快照進行更新的總數。
如果您打算排除 Reporting Services 存在的性能問題，記錄以下性能計數器通常很有幫助：ASP.NET、ASP.NET Applications、Process、System、Memory、Physical Disks、.NET Exceptions、.NET Memory、.NET Loading、.NET CLR Locks and Threads 以及 .NET CLR Data。
可選的 Reporting Services 性能計數器
以下列出了一些適用於 RS Web Service 但在默認情況下並未安裝的性能計數器。但是，在執行性能優化工作時，可以通過這些計數器來改善您洞察性能的能力。為實現這個目的，請在命令提示符中執行以下語句：
installutil.exe /u ReportingServicesLibrary.dll
然後再執行：
installutil.exe ReportingServicesLibrary.dll
為了成功執行該語句，您可能首先需要修改您的路徑，在路徑中包含 Microsoft .NET Framework 的安裝目錄。在路徑修改完畢後，請從包含 ReportingServicesLibrary.dll 文件的目錄下執行先前語句。默認情況下，該文件安裝在 C:\Program Files\Microsoft SQL Server\MSSQL\MSSQL.instance\Reporting Services\ReportServer\bin 目錄下。這些計數器沒有進行徹底的本地化。
Active Database Connections（活動資料庫連接）
某個時間處於活動狀態的資料庫連接的數量。只統計指向 Report Server 目錄的連接。
Active Datasource Connections（活動數據源連接）
某個時間處於活動狀態的資料庫連接的數量。只統計由當前運行的報告打開的數據源連接。
Active Threads（活動線程）
當前處於活動狀態的線程數量。在 Web 服務中，它包含一些為請求提供服務的線程。在交付服務中，它包含工作線程以及維護和輪詢線程。
Byte count（位元組計數）
對於上一次請求，在呈現當前報告時向客戶端返回的位元組數量。這與對應的執行日誌條目相類似。
Row Count（行計數）
對於上一次請求，由當前報告返回的行的數量。這與對應的執行日誌條目相類似。
Time in Compression（壓縮時間）
對於上一次請求，在快照和 PDF 報告壓縮上花費的時間（以毫秒計）。
Time in data source access（數據源訪問時間）
對於上一次請求，在獲取報告的數據源信息上花費的時間（以毫秒計）。其中包括執行查詢和取回結果所需的時間。這與對應的執行日誌條目相類似。
Time in database（資料庫時間）
對於上一次請求，在獲取 Report Server 目錄信息上花費的時間（以毫秒計）。
Time in processing（處理時間）
對於上一次請求，在報告處理上花費的時間（以毫秒計）。這與對應的執行日誌條目相類似。
Time in rendering（呈現時間）
對於上一次請求，在呈現報告上花費的時間（以毫秒計）。這與對應的執行日誌條目相類似。
3. 如何通過WebView監控提升WebAPP性能
相對於需要專業移動開發人員的原生應用（Native APP），基於HTML5/CSS/JavaScript的WebAPP憑借開發者門檻低、迭代迅速、支持跨平台發布等特點，成為電商、銀行等網路服務、瀏覽類應用的首選，然而由於頁面渲染導致的性能差距是WebAPP與原生應用無法抗衡的最大原因，因此針對WebView組件的性能優化就顯得至關重要。
為什麼是WebView
WebAPP所顯示的Web頁面都是由一個叫做WebView的組件渲染出來的，每個網頁都有一個鏈接即URL，首先將URL轉換成NSURLRequest，然後用載入網頁的類WebView載入Request，使用 - (void)loadRequest:(NSURLRequest *)request這個方法，就能將網頁載入顯示出來。
目前iOS中有兩個載入網頁的類，分別是UIWebView和WKWebView，UIWebView是UIKit框架中的一個類，而WKWebView是WebKit框架中的類，從性能上來說WKWebView的性能高、穩定性好、佔用內存小，完全優於UIWebView。但由於WKWebView是iOS8提供的組件，因此系統版本低於iOS 8.0的iPhone/iPad用戶就無法正常使用WKWebView組件開發出來的APP。所以目前大部分開發人員還在使用性能、穩定性並不理想的UIWebView進行WebAPP開發，而本文所說的雲智慧透視寶WebView性能監控也是以UIWebView為主要優化目標。
要進行性能監控必須獲得WebAPP頁面載入全過程的性能數據，透視寶是通過向當前載入鏈接的html5、jsp、php網頁代碼中注入獲取數據的JS代碼，然後通過OC與JS交互，將數據傳遞給OC，然後再將數據整理發送到透視寶後端。
監控哪些WebView性能數據
透視寶能監控四大類數據：
行為數據：抓取用戶在移動端網頁點的行為操作，也就是點擊網頁的內容，分析用戶的行為
時間相應數據：分解一個鏈接從載入開始到完成這段時間內，每個階段的耗時
Ajax請求數據：抓取終端用戶響應時間，響應數據下載時間，數據響應成功的callback執行時間和ajax錯誤數據
JS錯誤數據：抓取載入鏈接的代碼錯誤信息
① 時間響應數據及數據計算公式
（圖片來源：51cto技術博客）
參見上圖，JS傳給透視寶的時間響應數據就是這些欄位，其中navigationStart是起點，所有的計算都需要依賴於它。分析移動端H5性能數據，其實就是測算HTML5、JSP、PHP等網頁元素在iOS上載入的時間長短，通過這些性能數據前段開發人員能夠准確發現性能問題並及時解決，下表是透視寶定義的響應時間分解數據及計算方案：
② 資源時序數據
每一個網頁都是有很多資源組成的，包括.js、.png、.jpg、.css、script等，每一個元素的載入都需要載入時間，資源時序數據就是准確記錄每一個元素的載入時間及類型，並把這些數據通過JS的performance介面直接獲得並傳給OC，不需要計算。
③ JS錯誤及ajax請求數據
JS錯誤指的是抓取網頁代碼的錯誤，包括錯誤類型及堆棧信息，直接定位錯誤。ajax請求的數據有請求的鏈接、uri、 終端用戶響應時間，響應數據下載時間，數據響應成功的callback執行時間和ajax錯誤數據。JS錯誤和ajax請求數據都是有JS代碼直接獲取到，不需要處理。
JS代碼注入
想要准確監測網頁性能就需要進行代碼注入，而只有拿到網頁的代碼才能注入， UIWebView這個類裡面除了三個載入鏈接的方法和4個代理方法，就沒有其他內容了，而這些方法並不能獲取到內容，所以我們就需要考慮其他方法。UIWebView在載入攔截的時候會進入NSURLProtocol這個類，而恰好這個類能拿到當前載入鏈接NSURLRequest，而且會走進這個類的 - (void)startLoading方法，這個方法在頁面load完成之前，頁面剛載入之後，所以就是我們所需要的。
創建一個類，繼承NSURLProtocol這個類，重寫startLoading方法，由於能拿到鏈接的request，所以我們就對這個鏈接發送請求，用原生態的NSURLConnection或者NSURLSession都可以，我們用的NSURLConnection這個類發送請求並設置代理，方法是這個 - (nullableinstancetype)initWithRequest:(NSURLRequest*)request delegate:(nullableid)delegate startImmediately:(BOOL)startImmediately，
NSURLConnection的代理方法中有一個能接受請求鏈接數據的方法， - (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data，得到的NSData是16進制的位元組流數據，通過utf8轉碼將位元組流轉換成字元串，然後發現這個字元串正好是這個當前載入網頁的代碼，
網頁代碼都是由標簽組成，都會有<head>這個標簽，我們就把JS代碼注入到<head>標簽之下，放在自己添加的<script>標簽中;代碼實現就是獲取字元串中<head>這個字元的位置，然後在其下面插入用<script>包裝的js代碼，然後轉回成新的NSData的位元組流數據。
由於頁面還沒有載入，我們已經改動代碼了，就需要把注入JS代碼的重新記載一次，需要用NSURLProtocol的代理屬性NSURLProtocolClient，用NSURLProtocolClient這個中的這個方法- (void)URLProtocol:(NSURLProtocol*)protocol didLoadData:(NSData*)data，將新的NSData載入一次，轉回成NSData是因為這個方法需要的是NSData數據。
當然上面只是介紹主要實現的一些方法，還需要用到NSURLConnection的其他代理方法，只是這些方法不需要添加什麼，按照常規處理就行了，就不一一介紹了。
性能數據獲取
載入鏈接過程中JS代碼就會通過performance介面獲取數據，然後獲取的這些數據需要傳給移動端，如何傳遞數據呢，傳遞數據的過程也叫OC與JS交互的過程。
獲取數據的時機：
由於不清楚什麼時候JS能拿到數據，所以從最開始就需要進行交互的監控，也就是載入鏈接的時候，因為透視寶SDK用來監控的所以我們不能直接使用這個方法，需要用到OC的運行時，動態載入機制，又叫hook。首先通過添加UIWebView的類目，添加類目是將UIWebView類的實現分散出來，每個類都是由NSbject繼承下去，所以每個類都有 (void)load方法，而且這個方法的執行是最早的，我們就在這個方法中使用OC的運行時runtime，使用一個方法交換UIWebView載入鏈接的三個方法的指針，這樣就會在執行載入方法之前執行我們交換出來的方法，在這個方法裡面我們傳遞一個與JS匹配的標識，通過標識相同來獲取數據，這樣做的目的就是能從最開始就監控數據的傳遞。
4. 基於web技術的遠程監控的方式有哪些
希望這篇文章能對你有幫助：
Web Service使用可擴展標記語言(XML)作為基本的數據表示方式，消除了使用不同組件模型、操作系統和編程語言的系統之間所存在的差異。簡單對象訪問協議(SOAP，Simple Object Access Protocol)是用於交換XML編碼信息的輕量級協議。它的主要作用是為各類XML消息，提供一個簡單統一的傳輸機制。Web Service使用SOAP來包裝XML數據，通過HTTP(或MSMQ、SMTP、TCP/IP)作為傳輸協議，在不同平台、不同軟體、不同組織之間進行傳遞。Web Service的描述語言為WSDL。它提供了一種描述服務介面的標准方法，定義了一種描述介面的抽象語言，使服務的介面定義獨立於底層協議和編碼方式。通用描述、發現和集成(UDDI)是Web Service的信息注冊的標准規范，用來對服務提供動態的注冊功能。
可見，Web Service採用XML、SOAP、HTTP、WSDL、UDDI等標准協議。這些協議與特定的操作系統、對象模型和編程語言無關。因此，利用Web Service來建立遠程監控系統時
(1) 由於採用標準的協議，不受特定的開發者、平台、語言和數據編碼格式的限制;
(2) 開發的Web Service可以供不同的客戶調用;
(3) HTTP作為傳輸協議可以穿過防火牆，提供在Internet上的連接和訪問[8];
(4) 如果知道Web Service的地址並具有相應許可權，就可以在網路的任何地方進行調用。
3 遠程監控系統結構
為了實現工業過程的遠程監控，基於Web Service技術的遠程監控系統結構如圖4所示。
圖4 基於Web Service的遠程監控系統結構
3.1 基於Web Service的遠程監控系統結構
傳統的遠程監控系統多使用OPC技術來獲取各種現場設備的數據，包括實時采樣值、歷史數據、報警數據等等。該系統也使用OPC來與現場設備進行數據交換。圖4中的OPC伺服器由設備供應商提供。OPC技術是以Microsoft的OLE/COM 技術為基礎。因此，與其他組件技術一樣，它不是防火牆友好的，難以通過防火牆從OPC伺服器獲取所需的數據。即使在同一區域網內，位於不同計算機上的OPC客戶端要連接到OPC伺服器都需要經過復雜的DCOM和安全性設置，這增加了系統開發的難度，為此要對OPC伺服器的數據進行封裝。通過網關(命名為「過程網關」)的形式來為各個系統提供數據。過程網關作為OPC客戶端從OPC伺服器獲取各種過程數據，將這些數據按照一定規則重新組織，並封裝在Web Service內，過程網關也從已有的控制系統中獲取所需的數據，並以服務的形式暴露給各種應用。
Web已被廣泛用於監控系統中，它可以提供統一的人機界面，並且操作簡單友好。該系統結構使用Web來建立監控系統，Web監控系統通過過程網關獲取現場設備的數據，將這些數據以Web的形式提供給遠程用戶。遠程用戶通過PC、PDA、筆記本電腦或手機訪問Web頁，將各種控制數據送回Web監控系統。Web監控系統再將這些控制數據通過過程網關傳送給現場設備，這樣就完成了對現場設備的遠程監控。
當然，遠程的用戶也可以通過直接訪問過程網關來實現遠程的監控。由於Web監控系統以HTML的形式來傳送消息和過程網關提供的Web Service的防火牆友好性，因此不管使用那種方式來進行遠程監控，都不會受到防火牆的限制。
3.2 過程網關
過程網關是現場設備與監控系統的橋梁，起著重要的數據中轉作用，其結構如圖5所示。
圖5 過程網關與監控應用
(1) 數據獲取
過程網關需要獲取
來自現場的實時數據，以對工業過程進行及時的監控;
來自其他控制系統的數據，以允許監控應用與這些系統進行數據交互。
目前主要的自動化設備生產廠家，如Rockwell、Siemens等，都提供了對OPC技術支持，通過OPC來獲取現場設備的數據。OPC伺服器通過各種現場設備的驅動程序，直接從設備中取得數據，再將這些數據提供給OPC客戶端。OPC有幾種協議，分別有不同用途。例如，OPC客戶端通過OPC DA獲取設備或SCADA系統的數據;通過OPC AE獲取報警和事件信息;通過OPC HDA獲取過程式控制制中的歷史數據。
現場控制系統將各種數據存入資料庫中，過程網關通過訪問這些資料庫來獲取控制系統的數據。獲取這些數據的目的在於使遠程式控制制系統可以與已有的控制系統進行交互，方便地將這些系統集成到新的系統中，使其獲得新的生命周期。成熟的中間件技術，如ODBC、ADO等，為資料庫的訪問提供了簡單快捷的方法。
(2) 數據的Web Service封裝
通過4.2.1獲取的數據需要封裝為Web Service，以便Web監控系統和遠程用戶能夠進行調用。在進行數據封裝時，按照功能需求確定需要暴露給調用者的介面(類似於編程語言中的函數介面)，然後通過開發工具來開發這些Web Service。這些工具有Microsoft的Visual Studio.NET、IBM的WebSphere、Borland的JBuilder等等。數據封裝為Web Service後可以提供WSDL，方便調用者進行調用。
(3) 安全審查
過程網關的某些Web Service可能涉及到保密的數據，因此需要考慮數據傳輸的安全性，並對客戶端的訪問進行限制。可用多種方法來提供所需的安全性
採用WS-Security標准[9];
使用SSL進行加密和簽名;
使用傳輸層安全性(Transport Layer Security，TLS)、IPSec[10]等確保數據的安全傳輸;
使用伺服器，如IIS，的身份驗證功能;
提供用戶的角色定義和許可權分配。
(4) 服務調用
開發監控應用時，通過查找操作從本地或服務注冊中心檢索服務描述，然後進行Web監控系統的開發。而開發完成後的系統可以位於網路的任意位置。Web監控系統與過程網關提供的Web Service進行綁定，通過服務的調用實現數據的交互，由於Web監控系統的數據是通過純HTTP協議傳輸的，因此是防火牆友好的。
3.3 Web監控系統
監控系統可以有多種形式。傳統的監控系統通過各種組態軟體開發，如InTouch,iFix、RSView32等等，但這種監控系統一般是針對集散控制系統或現場匯流排控制系統的，不利於進行遠程的監控。每一種應用都需要相應的運行環境，這將增加用戶的投資，如採用基於Web的監控系統，就可以提供統一的人機界面，有利於進行遠程監控。
(1) Web監控
遠程的用戶可以通過瀏覽器訪問現場的運行畫面，掌握現場數據。同時可以通過瀏覽器發送控制命令，控制現場設備的運行。Web監控程序還可以實現數據存檔、報表列印、故障報警、統計圖表及曲線的顯示等[11]。在開發Web監控程序時，首先要獲取過程網關提供的WSDL(通過在服務注冊中心查找獲取，或直接通過過程網關Web Service所在的URL獲取)。在開發過程中，Web Service的使用與一般的API函數類似。為了提高性能，應盡量使用非同步調用的方式。ASP.NET、JSP等都可以用來進行Web監控程序的開發。由於終端設備的性能差異，需要為手機、PDA等設備開發不同於PC的Web監控程序。
(2) 沖突避免
如果多個用戶同時進行監控，可能會導致沖突，因此需要限制同時操作的用戶數量。當一個用戶訪問Web監控系統時，如果此時已經達到了允許的最大訪問數，則必須進行等待。此時，允許用戶查看各種數據，但屏蔽用戶的控制操作。當有其他的用戶斷開連接後，取消對該用戶控制操作的屏蔽，可允許其進行相應的控制。
(3) 許可權管理
許可權管理為每個用戶分配不同的許可權，只允許用戶進行授權范圍內的操作。至少應將用戶分為三個級別:管理員:主要負責對Web監控系統的管理和維護，對用戶進行管理;高級操作員:可以瀏覽各種數據，並進行相應的控制操作;一般操作員:只具有瀏覽數據的權利，不能進行修改。
不同的用戶登錄系統後具有不同的操作許可權，這樣可以防止控制操作的濫用，增強系統的安全性。
(4) 日誌管理
日誌可以記錄系統的運行情況以及用戶進行的各種操作，特別要記錄系統運行中出現的故障。對於用戶操作產生的日誌需要包括用戶名、所進行的操作、時間和IP地址。這樣可以掌握用戶所進行的各種操作，也便於在出現錯誤時進行追蹤和修復。
5. 如何保證Web伺服器安全
不但企業的門戶網站被篡改、資料被竊取，而且還成為了病毒與木馬的傳播者。有些Web管理員採取了一些措施，雖然可以保證門戶網站的主頁不被篡改，但是卻很難避免自己的網站被當作肉雞，來傳播病毒、惡意插件、木馬等等。筆者認為，這很大一部分原因是管理員在Web安全防護上太被動。他們只是被動的防禦。為了徹底提高Web伺服器的安全，筆者認為，Web安全要主動出擊。具體的來說，需要做到如下幾點。一、在代碼編寫時就要進行漏洞測試 現在的企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的，是通過代碼堆積起來的。如果這個代碼只供企業內部使用，那麼不會帶來多大的安全隱患。但是如果放在互聯網上使用的話，則這些為實現特定功能的代碼就有可能成為攻擊者的目標。筆者舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊，來獲取管理員的密碼等等破壞性的動作。有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時，其實就有可能在安裝一個木馬(這可能訪問者與被訪問者都沒有意識到)。 為此在為網站某個特定功能編寫代碼時，就要主動出擊。從編碼的設計到編寫、到測試，都需要認識到是否存在著安全的漏洞。筆者在日常過程中，在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。至少現在已知的病毒、木馬不能夠在你所開發的插件中有機可乘。通過這層層把關，就可以提高代碼編寫的安全性。二、對Web伺服器進行持續的監控 冰凍三尺、非一日之寒。這就好像人生病一樣，都有一個過程。病毒、木馬等等在攻擊Web伺服器時，也需要一個過程。或者說，在攻擊取得成功之前，他們會有一些試探性的動作。如對於一個採取了一定安全措施的Web伺服器，從攻擊開始到取得成果，至少要有半天的時間。如果Web管理員對伺服器進行了全天候的監控。在發現有異常行為時，及早的採取措施，將病毒與木馬阻擋在門戶之外。這種主動出擊的方式，就可以大大的提高Web伺服器的安全性。 筆者現在維護的Web伺服器有好幾十個。現在專門有一個小組，來全天候的監控伺服器的訪問。平均每分鍾都可以監測到一些試探性的攻擊行為。其中99%以上的攻擊行為，由於伺服器已經採取了對應的安全措施，都無功而返。不過每天仍然會遇到一些攻擊行為。這些攻擊行為可能是針對新的漏洞，或者採取了新的攻擊方式。在伺服器上原先沒有採取對應的安全措施。如果沒有及時的發現這種行為，那麼他們就很有可能最終實現他們的非法目的。相反，現在及早的發現了他們的攻擊手段，那麼我們就可以在他們採取進一步行動之前，就在伺服器上關掉這扇門，補上這個漏洞。 筆者在這里也建議，企業用戶在選擇互聯網Web伺服器提供商的時候，除了考慮性能等因素之外，還要評估服務提供商能否提供全天候的監控機制。在Web安全上主動出擊，及時發現攻擊者的攻擊行為。在他們採取進一步攻擊措施之前，就他們消除在萌芽狀態。 三、設置蜜罐，將攻擊者引向錯誤的方向 在軍隊中，有時候會給軍人一些偽裝，讓敵人分不清真偽。其實在跟病毒、木馬打交道時，本身就是一場無硝煙的戰爭。為此對於Web伺服器採取一些偽裝，也能夠將攻擊者引向錯誤的方向。等到供給者發現自己的目標錯誤時，管理員已經鎖定了攻擊者，從而可以及早的採取相應的措施。筆者有時候將這種主動出擊的行為叫做蜜罐效應。簡單的說，就是設置兩個伺服器。其中一個是真正的伺服器，另外一個是蜜罐。現在需要做的是，如何將真正的伺服器偽裝起來，而將蜜罐推向公眾。讓攻擊者認為蜜罐伺服器才是真正的伺服器。要做到這一點的話，可能需要從如下幾個方面出發。 一是有真有假，難以區分。如果要瞞過攻擊者的眼睛，那麼蜜罐伺服器就不能夠做的太假。筆者在做蜜罐伺服器的時候，80%以上的內容都是跟真的伺服器相同的。只有一些比較機密的信息沒有防治在蜜罐伺服器上。而且蜜罐伺服器所採取的安全措施跟真的伺服器事完全相同的。這不但可以提高蜜罐伺服器的真實性，而且也可以用來評估真實伺服器的安全性。一舉兩得。 二是需要有意無意的將攻擊者引向蜜罐伺服器。攻擊者在判斷一個Web伺服器是否值得攻擊時，會進行評估。如評估這個網站的流量是否比較高。如果網站的流量不高，那麼即使被攻破了，也沒有多大的實用價值。攻擊者如果沒有有利可圖的話，不會花這么大的精力在這個網站伺服器上面。如果要將攻擊者引向這個蜜罐伺服器的話，那麼就需要提高這個蜜罐伺服器的訪問量。其實要做到這一點也非常的容易。現在有很多用來交互流量的團隊。只要花一點比較小的投資就可以做到這一點。 三是可以故意開一些後門讓攻擊者來鑽。作為Web伺服器的管理者，不僅關心自己的伺服器是否安全，還要知道自己的伺服器有沒有被人家盯上。或者說，有沒有被攻擊的價值。此時管理者就需要知道，自己的伺服器一天被攻擊了多少次。如果攻擊的頻率比較高，管理者就高興、又憂慮。高興的是自己的伺服器價值還蠻大的，被這么多人惦記著。憂慮的是自己的伺服器成為了眾人攻擊的目標。就應該抽取更多的力量來關注伺服器的安全。四、專人對Web伺服器的安全性進行測試 俗話說，靠人不如靠自己。在Web伺服器的攻防戰上，這一個原則也適用。筆者建議，如果企業對於Web服務的安全比較高，如網站伺服器上有電子商務交易平台，此時最好設置一個專業的團隊。他們充當攻擊者的角色，對伺服器進行安全性的測試。這個專業團隊主要執行如下幾個任務。 一是測試Web管理團隊對攻擊行為的反應速度。如可以採用一些現在比較流行的攻擊手段，對自己的Web伺服器發動攻擊。當然這個時間是隨機的。預先Web管理團隊並不知道。現在要評估的是，Web管理團隊在多少時間之內能夠發現這種攻擊的行為。這也是考驗管理團隊全天候跟蹤的能力。一般來說，這個時間越短越好。應該將這個時間控制在可控的范圍之內。即使攻擊最後沒有成功，Web管理團隊也應該及早的發現攻擊的行為。畢竟有沒有發現、與最終有沒有取得成功，是兩個不同的概念。 二是要測試伺服器的漏洞是否有補上。畢竟大部分的攻擊行為，都是針對伺服器現有的漏洞所產生的。現在這個專業團隊要做的就是，這些已發現的漏洞是否都已經打上了安全補丁或者採取了對應的安全措施。有時候我們都沒有發現的漏洞是無能為力，但是對於這些已經存在的漏洞不能夠放過。否則的話，也太便宜那些攻擊者了。
6. 如何用java實現web伺服器的監控
Hyperic HQ集成了強大的監測和管理功能，它有開源版本，您可以直接使用它用來對web伺服器進行監控。
如果您想自己寫代碼實現，Hyperic HQ提供了一個伺服器各種性能指標採集的API，這個API包本身提供了各種平台(linux/MAC/window等)的兼容。
7. 在LoadRunner中監控WebSphere，關心的是哪些性能指標
不過TPV本來就並非定位為專業的監控工具，它提供的功能雖簡單，但能滿足我們分析過程中80%的需求。這個系列將介紹一些WebSphere下的監控和實時分析工具，希望能對TPV是個補充。這次介紹的是Mercury出品的Loadrunner。
「LoadRunner 是一種適用於各種體系架構的自動負載測試工具，通過模擬實際用戶的操作行為和實施實時性能監測，來幫助用戶排查和發現問題。」我們使用Loadrunner都是作為壓力測試工具，單用來作為監控工具有點大材小用。但在做壓力測試時，WebSphere的運行情況是重要的觀察對象之一。通過在Loadrunner中監控WebSphere，同時監控操作系統的資源佔用情況、Web伺服器的運行情況，可以對比各個時間點、時間段的應用表現。
8. 如何搭建 Web 前端性能監控系統的
網站性能優化時有很多網站專門做這個東西的你可以付費讓他們給你監控網站的運行情況和新增情況和網站在全國各地訪問情況有情況還會給你預警
9. 如何監控web伺服器主要性能指標
可以使用軟體開監控，拓建試試監控寶。會詳細記錄伺服器的數據指標
10. 有什麼好用的基於Web的Linux系統監控開源工具
可以用一些命令來實現你說的功能的。
請看下文，請採納。謝謝。
一、基於命令行的性能監控工具
1.dstat - 多類型資源統計工具
該命令整合了vmstat，iostat和ifstat三種命令。同時增加了新的特性和功能可以讓你能及時看到各種的資源使用情況，從而能夠使你對比和整合不同的資源使用情況。通過不同顏色和區塊布局的界面幫助你能夠更加清晰容易的獲取信息。它也支持將信息數據導出到cvs格式文件中，從而用其他應用程序打開，或者導入到資料庫中
2.atop - 相比top更好的ASCII碼體驗
這個使用ASCII碼顯示方式的命令行工具是一個顯示所有進程活動的性能監控工具。它可以展示每日的系統日誌以進行長期的進程活動分析，並高亮顯示過載的系統使用資源。它包含了CPU，內存，交換空間，磁碟和網路層的度量指標。所有這些功能只需在終端運行atop即可。
3.Nmon - 類Unix系統的性能監控
Nmon是Nigel's Monitor縮寫，它最早開發用來作為AIX的系統監控工具。如果使用在線模式，可以使用游標鍵在屏幕上操作實時顯示在終端上的監控信息。使用捕捉模式能夠將數據保存為CSV格式，方便進一步的處理和圖形化展示。
4.slabtop - 顯示內核slab緩存信息
這個應用能夠顯示緩存分配器是如何管理Linux內核中緩存的不同類型的對象。這個命令類似於top命令，區別是它的重點是實時顯示內核slab緩存信息。它能夠顯示按照不同排序條件來排序顯示緩存列表。它同時也能夠顯示一個slab層信息的統計信息的題頭。
5.sar - 性能監控和瓶頸檢查
sar 命令可以將操作系統上所選的累積活動計數器內容信息輸出到標准輸出上。其基於計數值和時間間隔參數的審計系統，會按照指定的時間間隔輸出指定次數的監控信息。如果時間間隔參數為設置為0，那麼sar命令將會顯示系統從開機到當時時刻的平均統計信息。有用的命令如下：
# sar -u 2 3
# sar -u -f /var/log/sa/sa05
# sar -P ALL 1 1
# sar -r 1 3
# sar -W 1 3
6.Saidar - 簡單的統計監控工具
Saidar是一個簡單且輕量的系統信息監控工具。雖然它無法提供大多性能報表，但是它能夠通過一個簡單明了的方式顯示最有用的系統運行狀況數據。你可以很容易地看到運行時間、平均負載、CPU、內存、進程、磁碟和網路介面統計信息。
Usage: saidar [-d delay] [-c] [-v] [-h]
-d 設置更新時間（秒）
-c 彩色顯示
-v 顯示版本號
-h 顯示本幫助
7.top - 經典的Linux任務管理工具
作為一個廣為人知的Linux工具，top是大多數的類Unix操作系統任務管理器。它可以顯示當前正在運行的進程的列表，用戶可以按照不同的條件對該列表進行排序。它主要顯示了系統進程對CPU和內存的使用狀況。top可以快速檢查是哪個或哪幾個進程掛起了你的系統
8.Sysdig - 系統進程的高級視圖
Sysdig是一個能夠讓系統管理員和開發人員以前所未有方式洞察其系統行為的監控工具。其開發團隊希望改善系統級的監控方式，通過提供關於存儲，進程，網路和內存子系統的統一有序以及粒度可見的方式來進行錯誤排查，並可以創建系統活動記錄文件以便你可以在任何時間輕松分析。