性能測試是發布新網站和新代碼的重要環節。全面性能測試決定了發布的成功或失敗。
在發布新網站和應用程序時,性能測試尤其重要,因為這時還沒有任何關于應用執行性能的歷史數據。應用程序框架、平臺和硬件的新技術也可能會開始起作用。硬件的變化是很快的,而使用最新發布的硬件來運行應用程序,其性能可能比六個月前預定的硬件高很多。
性能測試應該盡早執行,新產品的所有組件都應該先進行測試,然后才能進行開發。如果新硬件的容量達到了遺留系統硬件容量的兩倍水平,那么使應用架構產生相同性能的硬件需求就會少于過去開發的應用程序。
如果已經有一個可訪問和正常運行的Web應用程序,那么先給新應用程序分配一小部分測試帶寬(如果它將替代舊的應用程序),然后讓最終用戶試用新應用程序。這種“在生產環境中測試”的方法可以給我們提供一些非常寶貴的信息,從中可以了解當生產流量進人應用程序時它的執行情況。此外,我們也可以通過解析歷史Web日志來模擬一些生產流量,將這些流量導入到新應用程序上,從而測試它在生產環境的運行性能。然而,這仍然屬于一種合成測試,其測試結果肯定不同于公共互聯網的真實測覽器或客戶端成用程序的真頭流量的測試果。通過測量到達新應用程序的流量數量,或者將現有網站的一小部分用戶導入到新應用程序中,我們就可以獲得一些寶貴的信息,了解應用程序在正式發布和接收生產流量之后可能的執行情況。
1.本地性能測試
Web開發人員應該在專用服務器上創建Web應用程序實例,這個專用服務器要的硬件和環境配置都要跟新網站及其應用程序、數據庫或數據存儲將要使用的硬件和環境配置相類似。并不是每一位Web開發人員都能夠創建一個與生產環境類似的環境。然而,重要的是他們有足夠的可用資源,能創建最接近部署最終產品的生產環境。這可能意味著,Web開發人員要有一個塔式工作站,但是它的處理能力與運行生產網站的服務器相當。這樣可以保證開發應用程序的環境盡可能接近最終的生產環境。
保證網站或應用程序性能接近客戶所面對環境的另一種方法是,直接在一個與生產環境類似的測試環境上開發應用程序。這取決于快照時間表是否合理,以及目前有多少的試生產或分段環境,但是這樣做可以節約很多時間,因為本地開發者工作站通常無法反映Web應用程序在生產環境的真實性能。
本地測試可以直接通過使用一些自動化工具或瀏覽器插件完成。最使用真實Web瀏覽器去測試Web應用程序性能,因為它能夠更真實地反映網站的性能。大多數網站都是動態的,而 Jmeter I或 Apache Bench等自動化合成測試工具無法呈現動態內容,如 Javascript和CSs,而且它們會增加網站的響應時間。工具 Hammerhead支持在Ficx瀏覽器中重復加載一個網頁并清除緩存,從而可以幫助Web開發人員了解一個網頁的加載時間。 Firebug.則是另一個實用工具,它可以顯示Web瀏覽器呈現一個網頁所需要的時間,其中包括所有的動態內容。
如果本地測試發現頁面加載時間為1~3秒,而且網站本身沒有太多的圖片,那么這個網站就可能有一些問題。大多數網民都沒耐心,他們不愿意等待,特別是現在寬帶已經非常普及,早不是撥號上網的時期,用戶并不理解數據庫需要先執行一些査詢操作,然后才能呈現一個網頁。所以,在測試Web應用程序時,如果渲染時間超過3秒鐘,那么可能就要去掉一些需要加載的靜態內容或所執行的前端操作數量
2.緩存
許多公司會錯誤地決定購買一個內容交付網絡(CDN)。CDN通常是一種Web內容的反向代理,所以CDN公司會在各地配置Web服務器,它很像一個web性能監控公司。CDN不會在服務器上使用Web瀏覽器去定期測試網站的加載速度,而是將我們的網站服務器副本存儲到全國或全世界各地。使用CDN的主要原因是因為Web服務器所在位置與用戶所在位置不同,例如網站在加拿大多倫多,而用戶從美國堪薩斯州威奇托市訪問網站,所以網站加載時間就包括從多倫多到威奇托之間的數據加載時間。相反,CDN會使用一個Web服務器的反向代理將內容存到本地,所以當有人從威奇托訪問網站時,返回響應的是CDN公司位于威奇托的服務器,而不是多倫多的原始服務器,這樣就可以顯著減少響應時間。
許多CDN公司現在都會在服務中附加一些Web性能最佳實踐方法,如縮略或壓縮 Javascript、HTML和CSS內容的壓縮技術,甚至再添加層Web應用程序安全抽象。這些都是非常適合生產網站的服務,它們可以提高網站設計的性能,但是在解決性能問題時,工程師必須謹慎使用這些“罐裝”服務。緩存是一種加速和提升網站性能的好方法,但并不是一種修復性能問題的有效方法,我們應該在開發人員的本地工作站上解決性能問題。