這個是我在給一朋友說瀏覽器與服務器之間交流時用到的例子,感覺比容易理解,所以拿來分享一下。

   假設:

  1.  A、B、C三個人。

  2.  C欠A錢(這里不考慮多少)

  3.  B是專門要賬

   思考:

瀏覽器與服務器的信息傳遞次數:

   A對B說,C欠我錢,你幫我去要。B接到指令后就去找C要錢。

   B對C說,給我20塊錢。

   C說,沒有。

   B對C說,給我10塊錢。

   C說,沒有。

   B對C說,給我5塊錢。

   .........

   最后,B回來對A說,哎呀媽呀,C那丫的忒摳門了,一分錢沒有。

   對于A來講,只是來說,它只是讓B問C要錢,具體的B與C之間交互了幾次,A是不知道的,它所知道的就是B返回給它的結果,C一分錢沒有。

   瀏覽器與服務器傳遞數據的大?。?/p>

   還是上面的過程,A對B說,C欠我錢,你幫我去要。B接到指令后就去找C要錢。

   B對C說,給我20萬塊錢。

   C說,沒問題,沒支票,只有1元硬幣。

   ..........

   B終于把錢拿回來給A。A很納悶,怎么去了那么久,B委屈的說,丫的,C給我整了一堆硬幣,太重了,路上走的慢,都快累死我了。

   對于A來講,只是來說,它只是讓B問C要錢,誰知道C給的是支票還是硬幣。所以,B去要錢消耗的時間就很長。

   所以,要想提高瀏覽器對服務器的訪問速度,應該減少數據傳遞次數與數據傳遞的大小。

這樣就很自然的引出了瀏覽器的cookie 

   A在C哪里存了5毛錢。

   A對B說,我在C哪里存了5毛錢,你去拿來我看看。B跑去問C要了5毛錢回來給A看。

  過了一會,A又對B說,我在C哪里存了5毛錢,你去拿來我看看。B跑去問C要了5毛錢回來給A看。

  過了一會,A又對B說,我在C哪里存了5毛錢,你去拿來我看看。這次C煩了,對B說,你把錢放自己口袋里吧,等A要的時候,你來問我5毛的人民幣有沒有改版,沒有改版的話,你就直接把口袋里的5毛錢給A看就行了。

  在這里A就相當于我們用戶,B相當于瀏覽器,C是服務器。而cookie就是B的口袋,當然了cookie的用處還很多。比如我們登陸一個系統,提示我們是否保存密碼(有的還有期限比如,一個星期或一個月),如果我們保存了,下次再訪問登陸時,瀏覽器就已經幫我們填寫好了賬戶密碼或直接幫我們登陸。那這個賬戶密碼就放在我們瀏覽器的cookie中。

   為什么要說上面的例子呢?因為我們大部分的一部分性能測試是基于B/S架構系統的,理解了瀏覽器與服務器之間的數據傳遞,有助于我們理解性能測試。

----//在開始性能測試之前,我們需要知道什么?

     當客戶或老板把你叫來,對你說,去給我們系統做個性能測試,千萬別傻傻的說“好!”然后,就走了,我以前這么干過(那時不懂,打腫了臉充胖子),回到座位后,不知從何下手了。

   那么,我們需要知道什么呢?

 1. 性能測試的目的

  首先要知道客戶的要求。

  我把性能測試按目的分以下幾種

   1)客戶有明確要求

   這是一個好的結果,這說明客戶對性能測試有一定的了解,知道他們需要的系統要達到一個什么樣的標準。如:系統要求同時滿足100用戶登陸,平均每個用戶登陸時間不能超過5秒。這個需求很明確,當然也不排除一些不懂裝懂的用戶,提一些不現實的要求。

   不管怎么說,用戶提要求了,這個比較容易,你可以對現系統做一次性能測試,至于,是通過優化系統還是增加硬件設備才能達到要求。就不是我們考慮的問題了。

   2)只是想知道目前系統性能(容量測試)

   可以把我們的目的就是求得最大用戶數和最佳用戶數。但是,這仍然是比較含糊的一個需求,我們需要對系統做出分析,找出系統的壓力點。

   3)找出系統性能瓶頸

   這個同樣需要分析可能對系統造成瓶頸的邏輯業務,然后才能進行性能測試。

   4)了系統在長時間的壓力下性能狀況(強度測試)

   這個一般驗證系統的穩定性,因為系統一旦上線,就有可能會長期處在大用戶的訪問狀態,可能以前沒發現的一些問題就會暴漏出來。比較典型的就是內存溢出。

 2. 性能測試的環境

  確定了我們的測試目的,當然需要測試環境。這里的環境,我們需要考慮一下幾點

  1)硬件環境

我們需要了解被測服務器硬件配置,用于加壓客戶端的機子配置,CPU 內存  等

  2)軟件環境

   我們需要了解被測系統的架構,前端、中間件、服務器(這里指運行系統軟件服務器,如tomcat)、數據庫,以及他們的部署位置。

   用于加壓的客戶端采用什么性能測試工具進行加壓。

  3)網絡環境

   網絡環境很重要。在上面的幾個目的中,除了找出系統性能瓶頸可以在廣域網進行,因為這個目的可以不用設置太多的虛擬用戶,只要找出系統哪個地方影響了整個系統的性能就行。 

   其他目的的測試都需要在,局域網進行,不然你壓力工具所發送的請求都會卡死在網絡的傳輸過程中。

  3. 尋找系統的壓力點

  我們需要對系統的哪個頁面或業務進行加壓。這個不是自己想出來的,需要與開發人員的溝通。系統的首頁?系統的登錄?還是系統的交易過程?各個業務的用戶比例是多少?

  只有獲得有效的性能需求,才容易尋找和定位壓力點。