專利名稱：監控web應用程序性能的方法、系統和web服務器的制作方法
技術領域：
本申請涉及一種監控技木，尤其涉及一種監控web應用程序性能的方法、系統和web服務器。
背景技術：
一般HTTP (HyperText Markup Language,超文本置標語言)請求響應的耗時包括三部分1、發送請求時在網絡上消耗的時間；2、web程序處理http請求所消耗的時間；3、網絡傳輸響應內容的時間。當用戶反饋系統響應速度較慢的時候，一般維護人員都先檢查系統的各項指標以及應用的日志。但是在采用集群方式部署的環境下，維護人員很難定位用戶反映的有性能問題的請求是由哪臺服務器處理的，這樣就無法去檢查服務器的各項監控指標。即使維護人員定位到了處理請求的服務器，但是由于系統在高并發的環境下一段時間內會產生大量相同URL的請求日志，這樣也將無法使維護人員準確的定位到出現性能問題的請求日志。目前業界為了定位和分析web應用程序性能通用的手段是為系統添加各種監控，主要使用的監控方案有兩種方案一服務器端性能日志該方案的主要方式是在服務器端的日志中記錄處理每個請求的耗時以便日后從日志中分析問題。一種實現方式如下在Apache配置類似如下日志格式LogFormat;/ % h % u % t\'r % r\'r %> s % h\ ,r % {User-Agent} i \ " %D" combined以上日志格式的含義請參考//httpd. apache, org/docs/2. 0/mod/mod_log_conf ig. html#customlog其中最重要的是D”這個表示處理此次請求所用的時間，単位微秒。收集各臺服務器上的訪問日志，查找耗時較多的URL為后續性能優化提供依據。方案ニ 模擬客戶端請求監控該方案是使用程序模擬瀏覽器向系統發送請求，并記錄響應時間以便跟蹤分析問題。實現方式如下使用wget或httpclient等工具訪問某些URL,記錄服務器的響應時間。分析記錄的日志，查找耗時較多的URL為后續性能優化提供依據。因為方案一是在服務器端記錄請求的響應時間，在集群部署的情況下用戶的請求是隨機發送到集群中的某臺服務器上去處理。這樣就有ー個缺陷是無法定位到用戶請求發送到哪臺服務器上，這種情況下當在用戶反映系統響應慢的時候，系統維護人員無法定位到具體的服務器，此外除了定位具體機器有困難，在一臺機器上，對用戶短時間的類似操作也較難定位哪一條日志，因此也就難以有效監控web應用程序性能。因為方案ニ是在客戶端模擬用戶請求的方式來監控web應用程序性能，因此監控效果不佳，具體表現為I、這個監控的客戶端部署在哪里？如果用戶是分布在全國各地的，全國各地的網絡狀況都是不一樣的。這樣的監控即使是多處布點也不能完全反映代表各地的網絡情況。2、這種監控程序往往不能完全模擬用戶對系統的操作。首先，一個系統可能對用戶開放幾個到幾十上百的功能，監控程序很難將每個功能都模擬一遍。其次，很多功能這種監控程序無法模擬，比如電子商務中的在線下訂單、在線支付等應用服務。現有技術中，難以有效監控web應用程序性能或者監控效果不佳，對于該問題，目前尚未提出有效解決方案。

發明內容
本申請的主要目的是提供一種監控web應用程序性能的方法、系統和web服務器，以解決現有技術中難以有效監控web應用程序性能或者監控效果不佳的問題。 為了實現上述目的，根據本申請的ー個方面，提供了一種監控web應用程序性能的方法。本申請的監控web應用程序性能的方法包括web服務器在向應用服務器轉發客戶端請求后，接收應用服務器執行應用程序邏輯后返回給所述客戶端的響應內容，并為所述客戶端請求分配客戶端請求標識，然后，將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中，將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端，接收所述客戶端對應地提交的所述標識和通過所述頁面獲取的web應用程序性能反饋信息，然后將所述標識和所述web應用程序性能反饋信息對應地保存在數據庫中；分析裝置接收所述web應用程序性能反饋頁面獲取的反饋信息，在所述數據庫中搜索該反饋信息對應的客戶端請求標識，在所述日志中查詢該客戶端請求標識對應的響應時間，并在該響應時間大于預設值的情況下輸出該響應時間對應的應用服務器的網絡地址或輸出報m樣自
目 I R ノ K、ο進ー步地，將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端包括在作為所述響應內容的HTML代碼中記錄所述標識以及所述代碼，再將所述HTML代碼發送給所述客戶端。進ー步地,所述web應用程序性能反饋頁面中包含用于接收web應用程序性能反饋信息的表単。進ー步地，將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中之后，所述方法還包括從所述日志中查找大于預設時間值的所述響應時間，確定查找到的所述響應時間對應的應用服務器的網絡地址然后輸出該網絡地址。為了實現上述目的，根據本申請的另一方面，提供了ー種web服務器。本申請的web服務器包括第一接收模塊，用于接收應用服務器對客戶端請求的響應；分配模塊，用于為所述客戶端請求分配客戶端請求標識；保存模塊，用于將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中；第一發送模塊，用于將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端；第二接收模塊，用于接收所述客戶端通過所述頁面獲取并發送的web應用程序性能反饋信息以及對應該反饋信息發送的客戶端請求標識；第二發送模塊，用于將所述反饋信息和所述標識對應地發送至數據庫。為了實現上述目的，根據本申請的又一方面，提供了一種監控web應用程序性能的系統。本申請的監控web應用程序性能的系統包括web服務器和分析裝置，其中web服務器，用于在向應用服務器轉發客戶端請求后，接收應用服務器執行應用程序邏輯后返回給所述客戶端的響應內容，并為所述客戶端請求分配客戶端請求標識，然后，將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中，將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端，接收所述客戶端通過所述頁面獲取的web應用程序性能反饋信息，然后將所述標識和所述web應用程序性能反饋信息對應地保存在數據庫中；分析裝置，用于接收所述web應用程序性能反饋頁面獲取的反饋信息，在所述數據庫中搜索該反饋信息對應的客戶端請求標識，在所述日志中查詢該客戶端請求標識對應的響應時間，并在該響應時間大于預設值的情況下輸出該響應時間對應的應用服務器的網絡地址或輸出報警信息。進ー步地，所述web服務器包括第一接收模塊，用于接收應用服務器對客戶端請求的響應；分配模塊，用于為所述客戶端請求分配客戶端請求標識；保存模塊，用于將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中；第一發送模塊，用于將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端；第二接收模塊，用于接收所述客戶端通過所述頁面獲取的web應用程序性能反饋信息以及對應該反饋信息發送的客戶端請求標識；第二發送模塊，用于將所述反饋信息和所述標識對應地發送給數據庫。進ー步地，所述第一發送模塊還用于在作為所述響應內容的HTML代碼中記錄所述標識以及所述代碼，再將所述HTML代碼發送給所述客戶端。進ー步地，所述分析裝置包括接收模塊，用于接收所述web應用程序性能反饋頁面獲取的反饋信息；捜索模塊，用于在所述數據庫中搜索該反饋信息對應的客戶端請求標識；查詢模塊，用于在所述日志中查詢所述搜索模塊搜索到的客戶端請求標識對應的響應時間；分析輸出模塊，用于在所述查詢模塊查詢到的響應時間大于預設值的情況下輸出該響應時間對應的應用服務器的網絡地址。進ー步地，所述分析裝置包括查找模塊，用于從所述日志中查找大于預設時間值的所述響應時間，并且確定該響應時間所對應的應用服務器的網絡地址；提示模塊，用于輸出所述查找模塊確定的網絡地址。根據本申請的技術方案，為每個發往服務器的請求都設置ー個唯一的標識，這個標識在服務器端會記錄到日志、數據庫等介質中。同時發往客戶端的響應中在HTML內容或者HTTP頭信息(HTTP Headers)中會添加此唯一的標識，這樣就將用戶的請求和服務器端 的日志記錄進行了一一對應。當用戶需要反饋系統的性能問題的時候，用戶提交的反饋表單會將用戶發出的對應操作的唯一標識發送給服務器并記錄到數據庫中。系統的維護人員可以根據用戶反饋的唯一的標識搜索服務器的上的日志從而定位到有問題的服務器。采用本申請實施例的技術方案后用戶的每個請求都會被設置ー個唯一的標識。用戶所有的操作的響應時間都會被記錄到日志中。這樣就解決了如何全面監控用戶請求的問題。另外，本申請實施例的技術方案完全是在用戶進行系統的真實操作時進行監控。這樣可以真實記錄系統的響應時間，從而能分析出系統的性能問題是否是因為用戶當地網絡問題導致，解決了如何真實反映用戶所處的網絡環境的問題。因此，采用本申請實施例的技術方案，能夠有效監控web應用程序性能，獲得較佳的監控效果。


說明書附圖用來提供對本申請的進一歩理解，構成本申請的一部分，本申請的示意性實施例及其說明用于解釋本申請，并不構成對本申請的不當限定。在附圖中圖I是與本申請實施例有關的ー種網絡結構的示意圖；圖2是根據本申請實施例的監控web應用程序性能的方法在web服務器上執行的流程示意圖；
圖3是根據本申請實施例的監控web應用程序性能的方法在客戶端執行的流程示意圖；圖4是根據本申請實施例的監控web應用程序性能的方法的整體流程的示意圖；圖5是根據本申請實施例的網絡維護人員進行系統分析的主要流程的示意圖；圖6是根據本申請實施例的監控web應用程序性能的裝置的示意圖；圖7是根據本申請實施例的監控web應用程序性能的另ー種裝置的示意圖；圖8是根據本申請實施例的監控web應用程序性能的系統的示意圖。
具體實施例方式需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。下面將參考附圖并結合實施例來詳細說明本申請。圖I是與本申請實施例有關的ー種網絡結構的示意圖。如圖I所示，多個客戶端11通過Internet網絡12和防火墻13與負載均衡設備14連接，多個應用服務器15也通過web服務器16與負載均衡設備14連接。應用服務器15和web服務器16可以部署在同一臺計算機中。基于類似于圖I所示的網絡，用戶通過互聯網訪問部署在某個IDC(互聯網數據中心)機房的web服務。由于全國甚至是全球范圍內各地的網絡環境千差萬別，這就導致網絡本身會嚴重影響用戶在使用web應用時的體驗。在網絡層面應用用戶體驗的主要因素是網速。從圖I也可以看出除了互聯網本身的結構非常復雜外，應用程序的部署也有一定的復雜性。一般中大規模的企業應用都會采用集群方式部署。關于此處的“集群”，簡單解釋如下參考圖1，用戶的請求先由客戶端11經由Internet網絡12、防火墻13發送到負載均衡設備14，由負載均衡設備14通過一定的算法將請求轉發到應用服務器集群中的某一臺應用服務器15上，由這臺應用服務器15來響應用戶的請求，并將處理結果返回給客戶端11 ;處在集群里的每臺應用服務器15都是對等的關系，每臺應用服務器15都是互為備份，任何一臺或者幾臺服務器出現故障都不會影響整個集群為用戶正常提供服務。當web應用出現性能問題時最直接的表現就是打開網頁的速度很慢，當出現這種問題時對于系統的維護或開發人員來說首先需要定位出現此問題是否是由于應用程序的性能問題導致的。“打開網頁的速度很慢”也就是系統響應的速度慢。一般HTTP請求響應的時間包括兩部分I、web程序處理http請求所消耗的時間。當程序存在缺陷或者設計方案不合理的時候就有可能導致程序在處理用戶請求的時候會有較大的時間消耗。還有ー種可能是集群中的某些服務器由于硬件故障或者訪問壓力的増加也可能導致用戶請求處理耗時較大。2、網絡傳輸請求和響應內容時消耗的時間。由于用戶使用的網絡的帶寬等因素的影響不同網絡條件下的用戶對同一程序的同一功能的使用感受會有很大的區別。對于這個原因引起的系統響應慢的問題，一般可以通過改善網絡條件解決。從以上的分析可以看出，當系統的維護人員接到用戶關于性能問題的反饋時，首先需要定位問題出現在哪里，這里需要考慮兩方面的問題，首先，需要定位導致響應慢的問題是由于用戶的網絡環境問題還是程序本身的性能問題；其次，如果是程序的問題需要定 位當時處理用戶請求的那臺服務器，然后再結合一些硬件的監控以及程序的日志再來分析和解決程序的性能問題。圖2是根據本申請實施例的監控web應用程序性能的方法在web服務器上執行的流程示意圖。如圖2所示，web服務器在將客戶端的客戶端請求轉發至應用服務器，并由后者處理該請求之后，web服務器主要執行以下步驟步驟S21 :接收應用服務器對客戶端請求的響應。步驟S22 :為客戶端請求分配客戶端請求標識。步驟S221 :將應用服務器的網絡地址、應用服務器對客戶端請求的響應時間、以及客戶端請求標識三者相對應地保存在日志中。步驟S222 :將所述響應、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給提出客戶端請求的客戶端設備。步驟S221和步驟S222可以同步進行，也可以先執行步驟S222，再執行步驟S221。客戶端在收到上述的用于呈現web應用程序性能反饋頁面的代碼后，運行該代碼即在輸出裝置例如顯示器上呈現上述頁面，其中包含性能反饋表單，該表單中提示用戶填寫對于頁面性能反饋的評價，包括頁面打開的速度，以及頁面的其他表現。步驟S23 :接收客戶端提交的信息。這里的信息包括步驟S22中的客戶端請求標識，以及web應用程序性能反饋頁面獲取的反饋信息，并且由客戶端對應地一井保存在數據庫中。在步驟S23之后由分析裝置(所述分析裝置可以是內置于web服務器中的功能模塊，也可以是獨立于web服務器，具有分析功能的獨立服務器或其他計算裝置)繼續執行以下步驟步驟S24:在數據庫中捜索該反饋信息對應的客戶端請求標識，在日志中查詢該客戶端請求標識對應的響應時間。步驟S25 :判斷步驟S24中查詢得到的響應時間是否大于預設值，若是，則進入步驟S26，否則返回步驟S24。步驟S26 :輸出步驟S24中查詢得到的響應時間對應的應用服務器的網絡地址或輸出報警信息。在步驟S26之后，網絡管理人員能夠獲得響應較慢(大于預設值)的應用服務器的網絡地址，網絡管理人員可以調取該應用服務器的所有響應時間以進行分析；另外在步驟S26中也可以同時輸出步驟S24中查詢得到的響應時間供網絡管理人員參考。另一方面，根據步驟S23中收到的客戶端提交的信息，可以得知用戶認為哪些服務響應較慢。通過對比用戶指出的服務響應速度和應用服務器的實際響應時間，就能夠確定是應用服務器本身響應較慢還是用戶使用的網絡的性能不佳。圖3是根據本申請實施例的監控web應用程序性能的方法在客戶端執行的流程示意圖，主要包括如下步驟
步驟S31 :向web服務器發送客戶端請求。步驟S33 :接收web服務器對所述客戶端請求的響應。本步驟的響應中包含客戶端請求的標識和用于呈現web應用程序性能反饋頁面的代碼。步驟S35 :根據所述響應呈現所述反饋頁面。在本步驟中，反饋頁面是否呈現也可以由用戶決定，用戶需要提交性能反饋時候可以通過頁面的按鈕或者快捷鍵觸發從而打開反饋頁面。步驟S37 :通過呈現的反饋頁面獲取web應用程序性能反饋信息。步驟S39 :將所述請求標識和獲取的反饋信息對應地發送給提供web應用的應用服務器。將圖2和圖3所示的流程結合，可以得到圖4所示的流程，圖4是根據本申請實施例的監控web應用程序性能的方法的整體流程的示意圖。步驟S23中的數據庫可以和分析裝置設置在同一計算機中，圖4示出了這種情形。在實際的網絡系統中，可以將web服務器和應用服務器部署在同一臺計算機內，也可以分別部署在不同計算機內，這些計算機可以共享同一個數據庫，該數據庫在這里主要用于存儲圖2和圖3中涉及的數據，例如應用服務器的網絡地址、應用服務器對客戶端請求的響應時間、以及客戶端請求標識等。根據圖4所示的流程，用戶從客戶端發送的HTTP請求通過web服務器的轉發后到達應用服務器。應用服務器處理完成HTTP請求，將響應內容發送回客戶端。返回的響應內容會經過web服務器的過濾。在過濾過程中可在返回的HTML代碼中添加<meta/>標簽，在<meta/>標簽中會添加請求唯一標識(以下用UNIQUE_REQUEST_ID表示)的值。針對返回內容不是HTML代碼的AJAX調用，可以在HTTP Header中將UNIQUE_REQUEST_ID添加到新響應頭信息中。web服務器在響應內容處理完成后記錄日志。每一條日志至少包括應用服務器的網絡地址，例如URL的內容；UNIQUE_REQUEST_ID ;處理請求的服務器耗吋。web服務器在響應內容中加入UNIQUE_REQUEST_ID的同時還可以加入額外的js腳本。在提交反饋的時候可以觸發這個js腳本里的功能打開反饋頁面，在反饋頁面中詢問用戶對網絡的響應速度是否滿意，用戶根據自己對于網絡服務功能的使用體驗進行判斷，在判斷結果為“是”，即用戶滿意本次網絡服務的情況下流程結束，否則用戶填寫反饋表單。用戶提交表單以后，web服務器將UNIQUE_REQUEST_ID和反饋信息ー并保存在上述的數據庫中。在具有上述數據庫的情況下，可以由網絡維護人員按照圖5所示的流程進行系統分析。圖5是根據本申請實施例的網絡維護人員進行系統分析的主要流程的示意圖。在圖5所示的流程中，根據與用戶反饋信息一并提交的UNIQUE_REQUEST_ID查找服務器上記錄的請求響應耗時日志；根據日志所在的服務器或者日志中記錄的信息可以確定當時處理用戶請求的具體服務器；根據日志中記錄的處理請求的耗時可以定位導致性能問題的原因是出自網絡原因還是程序自身問題。這里程序自身的性能即體現了應用服務器的性能。圖6是根據本申請實施例的監控web應用程序性能的裝置的示意圖。該裝置可以安裝在作為web服務器和應用服務器的計算機中。如圖6所示，監控web應用程序性能的裝置60主要包括以下模塊第一接收模塊61，用于接收應用服務器對客戶端請求的響應；分配模塊62，用于為所述客戶端請求分配客戶端請求標識；保存模塊63，用于將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存； 發送模塊64，用于將所述響應和所述標識對應地發送給所述客戶端；第二接收模塊65，用于接收到包含有客戶端請求標識的查詢指令；客戶端反饋接收模塊66，用于接收客戶端提交的帶有請求標識的性能反饋信息并保存；輸出模塊67，用于根據所述查詢指令中的所述標識確定并輸出該標識對應的應用服務器的網絡地址和應用服務器對客戶端請求的響應時間。發送模塊還可以用于將所述標識添加到所述響應的HTTP消息頭中然后將所述響應發送給所述客戶端，還可以用于在所述響應的HTML代碼中記錄所述標識以及所述用于呈現web應用程序性能反饋頁面的代碼，再將所述HTML代碼發送給所述客戶端。圖7是根據本申請實施例的監控web應用程序性能的另ー種裝置的示意圖。該裝置可安裝在客戶端計算機中。如圖7所示，監控web應用程序性能的裝置70主要包括以下模塊請求模塊71，用于向web服務器發送客戶端請求；接收模塊72，用于接收所述web服務器對所述客戶端請求的響應，所述響應中包含所述客戶端請求的標識和用于呈現web應用程序性能反饋頁面的代碼；呈現模塊73，用于根據所述響應呈現所述反饋頁面；獲取模塊74，用于通過呈現的反饋頁面獲取web應用程序性能反饋信息；提交模塊75，用于將所述請求標識和反饋信息對應地發送給提供所述web應用的應用服務器。圖8是根據本申請實施例的監控web應用程序性能的系統的示意圖。如圖8所示，監控web應用程序性能的系統80主要包括web服務器81和分析裝置82。其中web服務器81用于在向應用服務器轉發客戶端請求后，接收應用服務器執行應用程序邏輯后返回給所述客戶端的響應內容，并為所述客戶端請求分配客戶端請求標識，然后，將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中，將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端，接收所述客戶端通過所述頁面獲取的web應用程序性能反饋信息，然后將所述標識和所述web應用程序性能反饋信息對應地保存在數據庫中；分析裝置82用于接收所述web應用程序性能反饋頁面獲取的反饋信息，在所述數據庫中搜索該反饋信息對應的客戶端請求標識，在所述日志中查詢該客戶端請求標識對應的響應時間，并在該響應時間大于預設值的情況下輸出該響應時間對應的應用服務器的網絡地址或輸出報警信息。分析裝置82的一種可選結構是包括接收模塊，用于接收所述web應用程序性能反饋頁面獲取的反饋信息；捜索模塊，用于在所述數據庫中搜索該反饋信息對應的客戶端請求標識；查詢模塊，用于在所述日志中查詢所述搜索模塊搜索到的客戶端請求標識對應的響應時間；分析輸出模塊，用于在所述查詢模塊查詢到的響應時間大于預設值的情況下輸出該響應時間對應的應用服務器的網絡地址。分析裝置82的另ー種可選結構是包括查找模塊和提示模塊，其中查找模塊用于從日志中查找大于預設時間值的所述響應時間，并且確定該響應時間所對應的應用服務器的網絡地址；提示模塊用于輸出查找模塊確定的網絡地址。提示模塊也可以將查找模塊查找到的響應時間和應用服務器的網絡地址ー并輸出。本申請實施例的技術方案可采用Apache作為web服務器來完成(當然不僅限于Apache,其他的web服務器如Nginx等也都可以實現)。可以在Apache上安裝mod_unique_idso為姆個web請求生產卩隹一標識并記錄到apache訪問日志中。然后，開發ー個module作為Apache的Filter,實現修改HTML代碼的功能。a.在head部分添加<meta/>標簽記 錄請求的卩隹ー標識；b.在head部分添加額外的js文件,新增的js文件主要功能是用戶可以通過事先設定的快捷鍵展現用戶問題反饋頁面，并對系統問題提供反饋功能。接下來當用戶需要反饋性能問題時觸發快捷鍵，填寫反饋表単。提交后系統會收集到用戶的反饋信息，其中包括UNIQUE_REQUEST_ID。這樣系統維護人員就可以通過這個唯一標識去分析事先記錄的Apache訪問日志以定位性能問題出在程序本身還是網絡傳輸問題。上述具體方案能夠在解決“定位系統性能問題”這ー難題的前提下同時做到對應用程序的代碼無侵入，不需要修改或添加任何業務代碼即可實現此功能。根據本申請實施例的技術方案，為每個發往服務器的請求都設置ー個唯一的標識，這個標識在服務器端會記錄到日志、數據庫等介質中。同時發往客戶端的響應中在HTML內容或者HTTP頭信息(HTTP Headers)中會添加此唯一的標識這樣就將用戶的請求和服務器端的日志記錄進行了一一對應。當用戶需要反饋系統的性能問題的時候，用戶提交的反饋表單會將用戶發出的對應操作的唯一標識發送給服務器并記錄到數據庫中。系統的維護人員可能根據用戶反饋的唯一的標識搜索服務器的上的日志從而定位到有問題的服務器。采用本申請實施例的技術方案后用戶的每個請求都會被設置ー個唯一的標識。用戶所有的操作的響應時間都會被記錄到日志中。這種就解決了如何全面監控用戶請求的問題。另外，本申請實施例的技術方案完全是在用戶進行系統的真實操作時進行監控。這樣可以真實記錄系統的響應時間，從而能分析出系統的性能問題是否是因為用戶當地網絡問題導致，解決了如何真實反映用戶所處的網絡環境的問題。因此，采用本申請實施例的技術方案，能夠有效監控web應用程序性能，獲得較佳的監控效果。顯然，本領域的技術人員應該明白，上述的本申請的各模塊或各步驟可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執行的程序代碼來實現，從而，可以將它們存儲在存儲裝置中由計算裝置來執行，或者根據它們分別制作集成電路模塊，或者根據它們中的多個模塊或步驟制作成單個集成電路模塊。這樣，本申請不限制于任何特定的硬件和軟件結合。
以上所述僅為本申請的優選實施例而已，并不用于限制本申請，對于本領域的技 術人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本申請的保護范圍之內。
權利要求
1.一種監控web應用程序性能的方法，其特征在于，包括 web服務器在向應用服務器轉發客戶端請求后，接收應用服務器執行應用程序邏輯后返回給所述客戶端的響應內容，并為所述客戶端請求分配客戶端請求標識，然后， 將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中， 將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端， 接收所述客戶端對應地提交的所述標識和通過所述頁面獲取的web應用程序性能反饋信息，然后將所述標識和所述web應用程序性能反饋信息對應地保存在數據庫中； 分析裝置接收所述web應用程序性能反饋頁面獲取的反饋信息，在所述數據庫中搜索該反饋信息對應的客戶端請求標識，在所述日志中查詢該客戶端請求標識對應的響應時間，并在該響應時間大于預設值的情況下輸出該響應時間對應的應用服務器的網絡地址或輸出報警信息。
2.根據權利要求I所述的方法，其特征在于，將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端包括在作為所述響應內容的HTML代碼中記錄所述標識以及所述代碼，再將所述HTML代碼發送給所述客戶端。
3.根據權利要求I所述的方法，其特征在于，所述web應用程序性能反饋頁面中包含用于接收web應用程序性能反饋信息的表單。
4.根據權利要求I所述的方法，其特征在于，將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中之后，所述方法還包括 從所述日志中查找大于預設時間值的所述響應時間，確定查找到的所述響應時間對應的應用服務器的網絡地址然后輸出該網絡地址。
5.—種web服務器,其特征在于,包括 第一接收模塊，用于接收應用服務器對客戶端請求的響應； 分配模塊，用于為所述客戶端請求分配客戶端請求標識； 保存模塊，用于將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中； 第一發送模塊，用于將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端； 第二接收模塊，用于接收所述客戶端通過所述頁面獲取并發送的web應用程序性能反饋信息以及對應該反饋信息發送的客戶端請求標識； 第二發送模塊，用于將所述反饋信息和所述標識對應地發送至數據庫。
6.一種監控web應用程序性能的系統，其特征在于，包括web服務器和分析裝置，其中web服務器，用干 在向應用服務器轉發客戶端請求后，接收應用服務器執行應用程序邏輯后返回給所述客戶端的響應內容，并為所述客戶端請求分配客戶端請求標識，然后， 將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中，將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端， 接收所述客戶端通過所述頁面獲取的web應用程序性能反饋信息，然后將所述標識和所述web應用程序性能反饋信息對應地保存在數據庫中； 分析裝置，用干 接收所述web應用程序性能反饋頁面獲取的反饋信息，在所述數據庫中搜索該反饋信息對應的客戶端請求標識，在所述日志中查詢該客戶端請求標識對應的響應時間，并在該響應時間大于預設值的情況下輸出該響應時間對應的應用服務器的網絡地址或輸出報警信息。
7.根據權利要求6所述的系統，其特征在于，所述web服務器包括 第一接收模塊，用于接收應用服務器對客戶端請求的響應； 分配模塊，用于為所述客戶端請求分配客戶端請求標識； 保存模塊，用于將所述應用服務器的網絡地址、所述應用服務器對所述客戶端請求的響應時間、以及所述客戶端請求標識三者相對應地保存在日志中； 第一發送模塊，用于將所述響應內容、所述標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給所述客戶端； 第二接收模塊，用于接收所述客戶端通過所述頁面獲取的web應用程序性能反饋信息以及對應該反饋信息發送的客戶端請求標識； 第二發送模塊，用于將所述反饋信息和所述標識對應地發送給數據庫。
8.根據權利要求7所述的系統，其特征在于，所述第一發送模塊還用于在作為所述響應內容的HTML代碼中記錄所述標識以及所述代碼，再將所述HTML代碼發送給所述客戶端。
9 根據權利要求6所述的系統，其特征在于，所述分析裝置包括 接收模塊，用于接收所述web應用程序性能反饋頁面獲取的反饋信息； 捜索模塊，用于在所述數據庫中搜索該反饋信息對應的客戶端請求標識； 查詢模塊，用于在所述日志中查詢所述搜索模塊搜索到的客戶端請求標識對應的響應時間； 分析輸出模塊，用于在所述查詢模塊查詢到的響應時間大于預設值的情況下輸出該響應時間對應的應用服務器的網絡地址。
10.根據權利要求6所述的系統，其特征在于，所述分析裝置包括 查找模塊，用于從所述日志中查找大于預設時間值的所述響應時間，并且確定該響應時間所對應的應用服務器的網絡地址； 提示模塊，用于輸出所述查找模塊確定的網絡地址。
全文摘要
本申請提供了一種監控web應用程序性能的方法、系統和web服務器，以解決現有技術中難以有效監控web應用程序性能或者監控效果不佳的問題。該方法包括web服務器在向應用服務器轉發客戶端請求后，接收應用服務器的響應內容，并為客戶端請求分配客戶端請求標識，然后將應用服務器的網絡地址、應用服務器對客戶端請求的響應時間、以及客戶端請求標識三者相對應地保存在日志中，將響應內容、標識和用于呈現web應用程序性能反饋頁面的代碼對應地發送給客戶端，接收客戶端對應地提交的標識和通過頁面獲取的web應用程序性能反饋信息，然后將標識和web應用程序性能反饋信息對應地保存在數據庫中；分析裝置對保存的數據以及日志進行分析以確定應用程序的性能。
文檔編號H04L29/08GK102684934SQ201110064820
公開日2012年9月19日 申請日期2011年3月17日 優先權日2011年3月17日
發明者何進, 余金波 申請人:阿里巴巴集團控股有限公司