很早就在用國外的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個方面的測試。
功能測試主要是測試系統報表的功能以及支持的框架及後端服務
性能測試主要關注的是部署和不部署APM探針時對應用性能的影響
穩定性主要看探針會不會給應用引入不穩定的因素和數據採集報表展現的可用性
一、功能測試 這個階段的測試主要是測試聽雲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已經公測了，大家可以去嘗試。