很早就在用國外的NewRelic（http://www.newrelic.com/）的APM產品來監測自己網站的PHP應用性能了。無奈國外 的服務從國內訪問起來實在是太慢了，雖然New Relic已經上市了，但是這訪問慢的問題卻是一直沒見好轉，反而越來越嚴重。可能是GFW時不時抽風所致，有時候還得翻牆才能訪問New Relic的報表。雖說翻牆是碼農們必備的技能，但是為了看個報表查個故障都要翻牆的話實在太麻煩了。 最近非常意外地發現國內也有提供和New Relic類似服務的廠商了。聽雲（http://www.tingyun.com/），國內老牌的網絡性能監測廠商基調網絡提供的APM Saas服務，也是2014年底開始公測他們針對PHP的性能管理產品聽雲Server。非常幸運地拿到了聽雲Server的試用帳號，這周在自己的測試 環境裡測試了一下，感覺還不錯，雖然暫時還達不到國外New Relic的成熟水平，但是基本已經可以使用了。這兩天抽時間總結了一下測試的過程和使用感受。 另外在OSChina上看到聽雲Server的QQ交流群：332097173 ，閒話少說，我們開始。 針對聽雲的PHP APM產品的測試，我主要關心的是功能、性能和穩定性，所以一共做了3個方面的測試。
一、功能測試
這個階段的測試主要是測試聽雲Server的PHP 探針都提供了哪些功能模塊，以及對PHP應用及其後端架構的支持程度。
測試環境：
為了比較全面地測試聽雲Server APM產品的功能，專門搭建了一個比較典型的PHP應用WordPress，並安裝了一些第三方插件和後端服務來模擬我在生產環境中用到的一些其他服務。測試環境的應用架構拓撲圖和組件列表如下：
組件類型 名稱 版本 備注 操作系統 CentOS 6.5 PHP PHP 5.3.3 安裝了以下擴展： mongo 1.4.4 memcache 3.0.5 mysql 5.1.73 redis 2.2.5 Web服務器 Apache httpd 2.2.15 使用mod_php 主應用 WordPress 4.0.1中文版 WordPress插件 Disable Google Fonts 1.1 為了去掉被牆掉的google fonts的引用 WordPress插件 Exec-PHP 4.9 可以直接在頁面和文章裡寫PHP代碼 數據庫 MySQL 5.1.73 WordPress主數據庫 NoSQL MongoDB 2.2.5 NoSQL Memcached 1.4.6 NoSQL Redis 文章一 普通文章：TEST Article /?p=4 這個文章的內容存在數據庫裡，訪問該文章頁面只會產生MySQL的服務訪問 文章二 MongoDB測試文章：MongoDB Test Article /?p=18 該文章直接在文章內容中使用PHP代碼從MongoDB中存取數據，訪問該文章除了產生MySQL的服務訪問之外還會訪問MongoDB數據庫。 文章三 Redis測試文章：Redis Test Article /?p=22 該文章直接在文章內容中使用 PHP代碼從Redis服務中存取數據，訪問該文章除了產生MySQL的訪問之外還會訪問Redis服務。 文章四 Memcached測試文章：Memcached Test Article /?p=20 該文章直接在文章內容中使用PHP代碼調用SimplePie從外部網站訂閱RSS，並將內容緩存在Memcached中c。因此訪問該文章頁面除了MySQL的訪問之外，還會產生外部HTTP調用和Memcached訪問。 APM探針 聽雲Server PHP探針 1.0.1 公開測試版本
測試環境配置表和拓撲圖
測試環境中，應用服務器和MySQL數據庫服務安裝在同一台服務上，其他三個NoSQL服務分別安裝在內網測試環境的其他機器上。使用單獨的一台 Linux服務器來模擬客戶端訪問網站和應用，在後續的性能測試中，為了減少網絡環境和其他服務對數據准確性的影響，在應用服務器和測試機上單獨加了兩塊 網卡並使用網線直連，使用獨立的IP地址段192.168.4.x。
測試流程：
1、在應用服務器上安裝了聽雲Server PHP探針，從客戶端測試機上使用wget爬蟲模式對整個網站進行模擬用戶的點擊訪問，客戶端保持訪問1個小時後，從各自的報表平台中對比數據和功能。
2、安裝完聽雲PHP探針後在測試之前完成數據庫和httpd服務的重啟。客戶端測試機上運行以下腳本來進行模擬訪問：
while true; do wget -r –spider http://192.168.2.30/; rm -rf 192.168.2.30; sleep 1; done
3、由於第一個測試是做功能性的測試，不考慮網絡性能的影響，因此使用的是192.168.2.x網段地址來進行模擬訪問。測試中，為了模擬應用出現的性能問題，還對MySQL數據庫做了一些人為的處理，來增加其查詢的時間，從而降低應用性能。
測試結果輸出： 1.功能模塊 聽雲Server提供的報表功能模塊與New Relic的APM比較類似，對於New Relic的老用戶來說，非常容易上手。
模塊名稱
聽雲
應用列表
概覽-應用一覽
關鍵事務
關鍵應用過程
應用概覽
情報匯總
拓撲圖
視圖
事務
Web應用過程
數據庫
數據庫
後台任務
後台任務
外部服務
外部應用
錯誤分析
錯誤
環境
應用環境變量
設置
設置
報告
2.性能指標 聽雲報表提供的性能指標主要包括以下的項目：
性能指標
聽雲
應用響應時間 √ 應用吞吐率（單位時間訪問量） √ 錯誤率 √ Apdex √ SQL性能 √ Memcached性能 √ Redis性能 √ MongoDB性能 √ 外部服務性能 √
在性能指標中，聽雲提供了Apdex指數這個重要的性能指標，想了解這個指數的同學可以移步Apdex組織官網（http://apdex.org /）進行深入的了解。我們知道這個指數最重要的是T值的設置和指數數據展示時必須同時展示T值，從圖表上來看，聽雲缺省的應用T值是0.5秒。
聽雲Apdex指數圖表
3.應用性能分解
聽雲在應用概覽中使用了堆疊面積圖對應用性能進行了分解展示，並且聽雲的響應時間分解相對比較完整，基本上覆蓋了國外的New Relic APM能提供的所有項目：應用層時間、阻塞時間、數據庫調用時間、Redis響應時間、Memcached響應時間、MongoDB響應時間和外部服務時 間，一共7項性能指標的分解。
聽雲響應時間分解圖表
4.拓撲圖功能
聽雲可以自動識別應用架構並繪制應用的邏輯拓撲圖。但是聽雲Server不支持拖動和點擊鑽取。只能通過鼠標懸停的方式展示各服務節點的性能趨勢圖。不過 在服務的識別和支持上做得相對比較全，包括Memcached, MongoDB, Redis, SQL數據庫和外部服務的主機在內的多個服務節點都可以正常的識別和展示。不過在展示外部服務上有一個bug：外部服務主機名展示錯誤並且有亂碼。
聽雲應用拓撲圖
5.事務性能分析功能 對應用中每個事務的性能分析來看，聽雲Server提供了事務列表和一系列性能圖表。
聽雲Server
的Web應用過程性能分析報表
聽雲Server的Web應用過程鑽取性能分解上可以分解到數據庫、代碼模塊、外部服務和NoSQL服務的性能耗時。
聽雲的Web應用過程分解可以看到代碼段、數據庫、NoSQL和外部服務調用
聽雲Server在Web事務分析上提供了trace功能，對特別慢的Web事務保留詳細的trace數據，數據裡會包括代碼模塊的耗時統計，代碼運行的流程和耗時，HTTP參數和請求過程中調用的SQL語句等等。
聽雲Server的Web過程追蹤分析展示的代碼運行過程數據很詳細。例如遇到對數據庫訪問的代碼段性能慢的時候，會在對應的代碼段上同時展示相關的SQL語句和詳細到代碼行的代碼調用堆棧信息，不過追蹤詳情中暫時沒有看到HTTP請求參數的展示。
聽雲Server的Web過程追蹤詳情可以展示慢的代碼調用堆棧和SQL查詢語句
6.SQL性能分析功能
在SQL性能的分析方面聽雲Server提供了SQL性能列表和一系列SQL性能、吞吐量的圖表來展示SQL語 句的性能問題。在列表的排序上，聽雲Server在提供按平均響應時間和吞吐量的排序的基礎上增加了按總耗時和Web過程組合的排序。 對於特別慢的SQL查詢，聽雲Server提供了慢SQL的記錄功能。同時，聽雲Server的慢SQL追蹤數據非常全面，除了慢查詢詳細的SQL語句 （還對SQL語句提供了混淆的功能，在後面的參數設置對比中會提到）之外，還提供了慢查詢的散點圖，執行該SQL語句的應用實例名稱，調用者PHP腳本， 該語句的執行計劃和詳細到代碼行的代碼調用堆棧信息。其中慢SQL查詢的散點圖非常直觀，可以一目了然地發現出現慢查詢的時間段和樣本的分布情況，而執行 計劃的分析也讓運維人員不需要再去找DBA手工分析SQL語句了，調用堆棧可以讓研發人員直接定位慢SQL查詢所在的代碼行。
聽雲Server提供的非常詳細的慢SQL查詢追蹤數據
7.錯誤追蹤
為了測試聽雲對錯誤分析的功能和准確性，我特地修改了WordPress上的一個頁面，在PHP代碼裡人為引入了一個語法錯誤，並在一段時間內讓應用的執行時間超過PHP應用的缺省最長執行時間（30s）。下圖是聽雲提供的應用錯誤率的統計圖表和錯誤日志列表。
聽雲Server的錯誤率圖表和錯誤列表
聽雲Server的錯誤分析還對錯誤類型進行了分類和排序，列出各種錯誤類型的占比情況。而且在錯誤日志的列表中，它也按錯誤類型將錯誤日志進行了 匯總和排序。對於錯誤的定義，聽雲也避免了錯誤率圖表裡的錯誤看起來應該是只計算E_ERROR級別的錯誤，但是列表中給出的卻包含了 E_WARNING, E_NOTICE等警告級別的錯誤信息，造成了圖表和列表錯誤數量的不一致的情況，而這些警告信息其實沒那麼重要，也是用戶不需要太關心的。
聽雲的ErrorTrace數據中提供了直觀的錯誤發生的散點圖、錯誤URI、錯誤時間段、應用實例、次數、錯誤信息、詳細到代碼行的錯誤調用堆棧，HTTP請求信息和請求參數等等，在國內應該是做的最好的。
聽雲Server的錯誤追蹤日志
8.參數設置
關於監測探針的設置，例如前面提到的ApdexT值的設置，聽雲Server提供了比較完善的功能，包括ApdexT 值、各種追蹤動作的阈值、采集參數選項、參數和SQL語句混淆等多個設置項。並且所有的設置項都可以在線設置完成並自動在指定的應用探針上生效，無需重啟 應用服務器。
參數和SQL語句的混淆功能非常重要，而SQL語句和頁面表單中的一些敏感字段，例如用戶名和密碼等等，都是必須進行混 淆才能傳出去的，否則會對應用的安全帶來比較大的隱患。而對trace數據（例如慢SQL查詢，慢事務）的采集，可以設置當查詢多慢之後再做trace數 據的采集，以避免采集過多的trace數據。
聽雲Server提供了比較完善的配置文件設置和線上參數設置功能，特別是線上修改參數設置無需重啟應用服務器的功能，還是非常有用的。
聽雲Server的應用設置
二、性能測試
對於APM產品特別是這種探針模式的APM產品是否成熟，除了功能之外，我最關心的就是對性能的影響。因為引入應用探針 本來就是為了解決應用的性能問題，如果因為探針而導致應用性能下降太厲害，那就得不償失了。早期有一些傳統的APM產品，就是由於性能下降太厲害只能在測 試環境中使用而無法在線上生產環境中使用。所以針對這個問題我專門設計了一個測試，來測試應用安裝和未安裝探針時的響應速度，從而評估探針對應用性能的影 響程度。
測試流程：
測試同樣是在客戶端測試機上模擬用戶的請求來看應用的響應速度，本次測試是對文章二（即只有MySQL訪問的文章）進行 模擬訪問的測試。並且，為了減少網絡對測試結果的影響，這次測試使用了直連網口IP來進行測試，並且進行大樣本量大訪問測試來得到更精確的統計結果。測試 工具使用簡單但是功能強大的ab（Apache Benchmark）來完成，兩次測試分別是在不安裝探針、安裝聽雲探針的應用環境下完成的，每次測試都使用ab對測試目標URL進行1萬次訪問，並發數 為10。每次測試前都重啟被測試的應用服務器。使用以下命令進行測試：
ab -c 10 -n 10000 “http://192.168.4.2/?p=4″
測試結果：
最終的測試結果如下，下面分別是不帶探針、安裝聽雲探針的測試結果拷屏：
不安裝任何探針的測試結果
安裝聽雲Server探針的測試結果
性能測試結果匯總
測試環境
平均值 (ms)
影響(ms)
標准差(ms)
中位值(ms)
最小值(ms)
最大值(ms)
不安裝探針
1244
-
66.4
1233
781
2531
安裝聽雲探針
1349
105
72.4
1340
789
2813
從測試結果來看，聽雲Server的探針會帶來105毫秒的性能下降。對應用性能的影響在可接受的范圍之內。
三、穩定性測試
穩定性應該是APM產品最基本的要求了，首先不能因為安裝了應用探針影響應用的穩定性，其次對產品本身包括探針和報表必 須穩定，可以不間斷提供持續的服務。穩定性的測試需要長時間復雜的應用環境來進行測試，由於沒有這麼多時間來折騰，我只使用測試一的功能測試方法做了一天 的連續測試。測試結果如下：
聽雲Server的產品在測試期間始終正常采集並展示數據
從測試的結果來看，聽雲Server的探針和報表都比較穩定，在一天的持續測試中，始終正常工作並且在報表上數據展示也是連續的。
四、結論
從這幾天的測試結果來看，聽雲目前的產品還比較完善，除了個別小bug之外，基本可以達到在生產環境中使用的水平。後續會嘗試在生產環境中找幾個應用節點部署試試，聽說聽雲Server已經公測了，大家可以去嘗試。
原文：http://www.imsiren.com/archives/1192
