很早就在用國(guó)外的NewRelic的APM產(chǎn)品來監(jiān)測(cè)自己網(wǎng)站的PHP應(yīng)用性能了。無奈國(guó)外的服務(wù)從國(guó)內(nèi)訪問起來實(shí)在是太慢了，雖然New Relic已經(jīng)上市了，但是這訪問慢的問題卻是一直沒見好轉(zhuǎn)，反而越來越嚴(yán)重?？赡苁荊FW時(shí)不時(shí)抽風(fēng)所致，有時(shí)候還得翻墻才能訪問New Relic的報(bào)表。雖說翻墻是碼農(nóng)們必備的技能，但是為了看個(gè)報(bào)表查個(gè)故障都要翻墻的話實(shí)在太麻煩了。 最近非常意外地發(fā)現(xiàn)國(guó)內(nèi)也有提供和New Relic類似服務(wù)的廠商了。聽云(http://www.tingyun.com/)，國(guó)內(nèi)老牌的網(wǎng)絡(luò)性能監(jiān)測(cè)廠商基調(diào)網(wǎng)絡(luò)提供的APM Saas服務(wù)，也是2014年底開始公測(cè)他們針對(duì)PHP的性能管理產(chǎn)品聽云Server。非常幸運(yùn)地拿到了聽云Server的試用帳號(hào)，這周在自己的測(cè)試環(huán)境里測(cè)試了一下，感覺還不錯(cuò)，雖然暫時(shí)還達(dá)不到國(guó)外New Relic的成熟水平，但是基本已經(jīng)可以使用了。這兩天抽時(shí)間總結(jié)了一下測(cè)試的過程和使用感受。 另外在OSChina上看到聽云Server的QQ交流群：332097173 ，閑話少說，我們開始。 針對(duì)聽云的PHP APM產(chǎn)品的測(cè)試，我主要關(guān)心的是功能、性能和穩(wěn)定性，所以一共做了3個(gè)方面的測(cè)試。

功能測(cè)試主要是測(cè)試系統(tǒng)報(bào)表的功能以及支持的框架及后端服務(wù)

性能測(cè)試主要關(guān)注的是部署和不部署APM探針時(shí)對(duì)應(yīng)用性能的影響

穩(wěn)定性主要看探針會(huì)不會(huì)給應(yīng)用引入不穩(wěn)定的因素和數(shù)據(jù)采集報(bào)表展現(xiàn)的可用性

一、功能測(cè)試

這個(gè)階段的測(cè)試主要是測(cè)試聽云Server的PHP 探針都提供了哪些功能模塊，以及對(duì)PHP應(yīng)用及其后端架構(gòu)的支持程度。

測(cè)試環(huán)境：

為了比較全面地測(cè)試聽云Server APM產(chǎn)品的功能，專門搭建了一個(gè)比較典型的PHP應(yīng)用WordPress，并安裝了一些第三方插件和后端服務(wù)來模擬我在生產(chǎn)環(huán)境中用到的一些其他服務(wù)。測(cè)試環(huán)境的應(yīng)用架構(gòu)拓?fù)鋱D和組件列表如下：

測(cè)試環(huán)境配置表和拓?fù)鋱D

測(cè)試環(huán)境中，應(yīng)用服務(wù)器和MySQL數(shù)據(jù)庫(kù)服務(wù)安裝在同一臺(tái)服務(wù)上，其他三個(gè)NoSQL服務(wù)分別安裝在內(nèi)網(wǎng)測(cè)試環(huán)境的其他機(jī)器上。使用單獨(dú)的一臺(tái)Linux服務(wù)器來模擬客戶端訪問網(wǎng)站和應(yīng)用，在后續(xù)的性能測(cè)試中，為了減少網(wǎng)絡(luò)環(huán)境和其他服務(wù)對(duì)數(shù)據(jù)準(zhǔn)確性的影響，在應(yīng)用服務(wù)器和測(cè)試機(jī)上單獨(dú)加了兩塊網(wǎng)卡并使用網(wǎng)線直連，使用獨(dú)立的IP地址段192.168.4.x。

測(cè)試流程：

1、在應(yīng)用服務(wù)器上安裝了聽云Server PHP探針，從客戶端測(cè)試機(jī)上使用wget爬蟲模式對(duì)整個(gè)網(wǎng)站進(jìn)行模擬用戶的點(diǎn)擊訪問，客戶端保持訪問1個(gè)小時(shí)后，從各自的報(bào)表平臺(tái)中對(duì)比數(shù)據(jù)和功能。

2、安裝完聽云PHP探針后在測(cè)試之前完成數(shù)據(jù)庫(kù)和httpd服務(wù)的重啟。客戶端測(cè)試機(jī)上運(yùn)行以下腳本來進(jìn)行模擬訪問：

3、由于第一個(gè)測(cè)試是做功能性的測(cè)試，不考慮網(wǎng)絡(luò)性能的影響，因此使用的是192.168.2.x網(wǎng)段地址來進(jìn)行模擬訪問。測(cè)試中，為了模擬應(yīng)用出現(xiàn)的性能問題，還對(duì)MySQL數(shù)據(jù)庫(kù)做了一些人為的處理，來增加其查詢的時(shí)間，從而降低應(yīng)用性能。

測(cè)試結(jié)果輸出： 1.功能模塊 聽云Server提供的報(bào)表功能模塊與New Relic的APM比較類似，對(duì)于New Relic的老用戶來說，非常容易上手。

2.性能指標(biāo) 聽云報(bào)表提供的性能指標(biāo)主要包括以下的項(xiàng)目：

在性能指標(biāo)中，聽云提供了Apdex指數(shù)這個(gè)重要的性能指標(biāo)，想了解這個(gè)指數(shù)的同學(xué)可以移步Apdex組織官網(wǎng)(http://apdex.org/)進(jìn)行深入的了解。我們知道這個(gè)指數(shù)最重要的是T值的設(shè)置和指數(shù)數(shù)據(jù)展示時(shí)必須同時(shí)展示T值，從圖表上來看，聽云缺省的應(yīng)用T值是0.5秒。

聽云Apdex指數(shù)圖表

3.應(yīng)用性能分解

聽云在應(yīng)用概覽中使用了堆疊面積圖對(duì)應(yīng)用性能進(jìn)行了分解展示，并且聽云的響應(yīng)時(shí)間分解相對(duì)比較完整，基本上覆蓋了國(guó)外的New Relic APM能提供的所有項(xiàng)目：應(yīng)用層時(shí)間、阻塞時(shí)間、數(shù)據(jù)庫(kù)調(diào)用時(shí)間、Redis響應(yīng)時(shí)間、Memcached響應(yīng)時(shí)間、MongoDB響應(yīng)時(shí)間和外部服務(wù)時(shí)間，一共7項(xiàng)性能指標(biāo)的分解。

聽云響應(yīng)時(shí)間分解圖表

4.拓?fù)鋱D功能

聽云可以自動(dòng)識(shí)別應(yīng)用架構(gòu)并繪制應(yīng)用的邏輯拓?fù)鋱D。但是聽云Server不支持拖動(dòng)和點(diǎn)擊鉆取。只能通過鼠標(biāo)懸停的方式展示各服務(wù)節(jié)點(diǎn)的性能趨勢(shì)圖。不過在服務(wù)的識(shí)別和支持上做得相對(duì)比較全，包括Memcached, MongoDB, Redis, SQL數(shù)據(jù)庫(kù)和外部服務(wù)的主機(jī)在內(nèi)的多個(gè)服務(wù)節(jié)點(diǎn)都可以正常的識(shí)別和展示。不過在展示外部服務(wù)上有一個(gè)bug：外部服務(wù)主機(jī)名展示錯(cuò)誤并且有亂碼。

聽云應(yīng)用拓?fù)鋱D

5.事務(wù)性能分析功能 對(duì)應(yīng)用中每個(gè)事務(wù)的性能分析來看，聽云Server提供了事務(wù)列表和一系列性能圖表。

聽云Server的Web應(yīng)用過程性能分析報(bào)表

聽云Server的Web應(yīng)用過程鉆取性能分解上可以分解到數(shù)據(jù)庫(kù)、代碼模塊、外部服務(wù)和NoSQL服務(wù)的性能耗時(shí)。

聽云的Web應(yīng)用過程分解可以看到代碼段、數(shù)據(jù)庫(kù)、NoSQL和外部服務(wù)調(diào)用

聽云Server在Web事務(wù)分析上提供了trace功能，對(duì)特別慢的Web事務(wù)保留詳細(xì)的trace數(shù)據(jù)，數(shù)據(jù)里會(huì)包括代碼模塊的耗時(shí)統(tǒng)計(jì)，代碼運(yùn)行的流程和耗時(shí)，HTTP參數(shù)和請(qǐng)求過程中調(diào)用的SQL語句等等。

聽云Server的Web過程追蹤分析展示的代碼運(yùn)行過程數(shù)據(jù)很詳細(xì)。例如遇到對(duì)數(shù)據(jù)庫(kù)訪問的代碼段性能慢的時(shí)候，會(huì)在對(duì)應(yīng)的代碼段上同時(shí)展示相關(guān)的SQL語句和詳細(xì)到代碼行的代碼調(diào)用堆棧信息，不過追蹤詳情中暫時(shí)沒有看到HTTP請(qǐng)求參數(shù)的展示。

聽云Server的Web過程追蹤詳情可以展示慢的代碼調(diào)用堆棧和SQL查詢語句

6.SQL性能分析功能

在SQL性能的分析方面聽云Server提供了SQL性能列表和一系列SQL性能、吞吐量的圖表來展示SQL語句的性能問題。在列表的排序上，聽云Server在提供按平均響應(yīng)時(shí)間和吞吐量的排序的基礎(chǔ)上增加了按總耗時(shí)和Web過程組合的排序。   對(duì)于特別慢的SQL查詢，聽云Server提供了慢SQL的記錄功能。同時(shí)，聽云Server的慢SQL追蹤數(shù)據(jù)非常全面，除了慢查詢?cè)敿?xì)的SQL語句(還對(duì)SQL語句提供了混淆的功能，在后面的參數(shù)設(shè)置對(duì)比中會(huì)提到)之外，還提供了慢查詢的散點(diǎn)圖，執(zhí)行該SQL語句的應(yīng)用實(shí)例名稱，調(diào)用者PHP腳本，該語句的執(zhí)行計(jì)劃和詳細(xì)到代碼行的代碼調(diào)用堆棧信息。其中慢SQL查詢的散點(diǎn)圖非常直觀，可以一目了然地發(fā)現(xiàn)出現(xiàn)慢查詢的時(shí)間段和樣本的分布情況，而執(zhí)行計(jì)劃的分析也讓運(yùn)維人員不需要再去找DBA手工分析SQL語句了，調(diào)用堆?？梢宰屟邪l(fā)人員直接定位慢SQL查詢所在的代碼行。

聽云Server提供的非常詳細(xì)的慢SQL查詢追蹤數(shù)據(jù)

7.錯(cuò)誤追蹤

為了測(cè)試聽云對(duì)錯(cuò)誤分析的功能和準(zhǔn)確性，我特地修改了WordPress上的一個(gè)頁面，在PHP代碼里人為引入了一個(gè)語法錯(cuò)誤，并在一段時(shí)間內(nèi)讓應(yīng)用的執(zhí)行時(shí)間超過PHP應(yīng)用的缺省最長(zhǎng)執(zhí)行時(shí)間(30s)。下圖是聽云提供的應(yīng)用錯(cuò)誤率的統(tǒng)計(jì)圖表和錯(cuò)誤日志列表。

聽云Server的錯(cuò)誤率圖表和錯(cuò)誤列表

聽云Server的錯(cuò)誤分析還對(duì)錯(cuò)誤類型進(jìn)行了分類和排序，列出各種錯(cuò)誤類型的占比情況。而且在錯(cuò)誤日志的列表中，它也按錯(cuò)誤類型將錯(cuò)誤日志進(jìn)行了匯總和排序。對(duì)于錯(cuò)誤的定義，聽云也避免了錯(cuò)誤率圖表里的錯(cuò)誤看起來應(yīng)該是只計(jì)算E_ERROR級(jí)別的錯(cuò)誤，但是列表中給出的卻包含了E_WARNING, E_NOTICE等警告級(jí)別的錯(cuò)誤信息，造成了圖表和列表錯(cuò)誤數(shù)量的不一致的情況，而這些警告信息其實(shí)沒那么重要，也是用戶不需要太關(guān)心的。

聽云的ErrorTrace數(shù)據(jù)中提供了直觀的錯(cuò)誤發(fā)生的散點(diǎn)圖、錯(cuò)誤URI、錯(cuò)誤時(shí)間段、應(yīng)用實(shí)例、次數(shù)、錯(cuò)誤信息、詳細(xì)到代碼行的錯(cuò)誤調(diào)用堆棧，HTTP請(qǐng)求信息和請(qǐng)求參數(shù)等等，在國(guó)內(nèi)應(yīng)該是做的最好的。

聽云Server的錯(cuò)誤追蹤日志

8.參數(shù)設(shè)置

關(guān)于監(jiān)測(cè)探針的設(shè)置，例如前面提到的ApdexT值的設(shè)置，聽云Server提供了比較完善的功能，包括ApdexT值、各種追蹤動(dòng)作的閾值、采集參數(shù)選項(xiàng)、參數(shù)和SQL語句混淆等多個(gè)設(shè)置項(xiàng)。并且所有的設(shè)置項(xiàng)都可以在線設(shè)置完成并自動(dòng)在指定的應(yīng)用探針上生效，無需重啟應(yīng)用服務(wù)器。

參數(shù)和SQL語句的混淆功能非常重要，而SQL語句和頁面表單中的一些敏感字段，例如用戶名和密碼等等，都是必須進(jìn)行混淆才能傳出去的，否則會(huì)對(duì)應(yīng)用的安全帶來比較大的隱患。而對(duì)trace數(shù)據(jù)(例如慢SQL查詢，慢事務(wù))的采集，可以設(shè)置當(dāng)查詢多慢之后再做trace數(shù)據(jù)的采集，以避免采集過多的trace數(shù)據(jù)。

聽云Server提供了比較完善的配置文件設(shè)置和線上參數(shù)設(shè)置功能，特別是線上修改參數(shù)設(shè)置無需重啟應(yīng)用服務(wù)器的功能，還是非常有用的。

聽云Server的應(yīng)用設(shè)置

二、性能測(cè)試

對(duì)于APM產(chǎn)品特別是這種探針模式的APM產(chǎn)品是否成熟，除了功能之外，我最關(guān)心的就是對(duì)性能的影響。因?yàn)橐霊?yīng)用探針本來就是為了解決應(yīng)用的性能問題，如果因?yàn)樘结樁鴮?dǎo)致應(yīng)用性能下降太厲害，那就得不償失了。早期有一些傳統(tǒng)的APM產(chǎn)品，就是由于性能下降太厲害只能在測(cè)試環(huán)境中使用而無法在線上生產(chǎn)環(huán)境中使用。所以針對(duì)這個(gè)問題我專門設(shè)計(jì)了一個(gè)測(cè)試，來測(cè)試應(yīng)用安裝和未安裝探針時(shí)的響應(yīng)速度，從而評(píng)估探針對(duì)應(yīng)用性能的影響程度。

測(cè)試流程：

測(cè)試同樣是在客戶端測(cè)試機(jī)上模擬用戶的請(qǐng)求來看應(yīng)用的響應(yīng)速度，本次測(cè)試是對(duì)文章二(即只有MySQL訪問的文章)進(jìn)行模擬訪問的測(cè)試。并且，為了減少網(wǎng)絡(luò)對(duì)測(cè)試結(jié)果的影響，這次測(cè)試使用了直連網(wǎng)口IP來進(jìn)行測(cè)試，并且進(jìn)行大樣本量大訪問測(cè)試來得到更精確的統(tǒng)計(jì)結(jié)果。測(cè)試工具使用簡(jiǎn)單但是功能強(qiáng)大的ab(Apache Benchmark)來完成，兩次測(cè)試分別是在不安裝探針、安裝聽云探針的應(yīng)用環(huán)境下完成的，每次測(cè)試都使用ab對(duì)測(cè)試目標(biāo)URL進(jìn)行1萬次訪問，并發(fā)數(shù)為10。每次測(cè)試前都重啟被測(cè)試的應(yīng)用服務(wù)器。使用以下命令進(jìn)行測(cè)試：

測(cè)試結(jié)果：

最終的測(cè)試結(jié)果如下，下面分別是不帶探針、安裝聽云探針的測(cè)試結(jié)果拷屏：

不安裝任何探針的測(cè)試結(jié)果

安裝聽云Server探針的測(cè)試結(jié)果

性能測(cè)試結(jié)果匯總

從測(cè)試結(jié)果來看，聽云Server的探針會(huì)帶來105毫秒的性能下降。對(duì)應(yīng)用性能的影響在可接受的范圍之內(nèi)。

三、穩(wěn)定性測(cè)試

穩(wěn)定性應(yīng)該是APM產(chǎn)品最基本的要求了，首先不能因?yàn)榘惭b了應(yīng)用探針影響應(yīng)用的穩(wěn)定性，其次對(duì)產(chǎn)品本身包括探針和報(bào)表必須穩(wěn)定，可以不間斷提供持續(xù)的服務(wù)。穩(wěn)定性的測(cè)試需要長(zhǎng)時(shí)間復(fù)雜的應(yīng)用環(huán)境來進(jìn)行測(cè)試，由于沒有這么多時(shí)間來折騰，我只使用測(cè)試一的功能測(cè)試方法做了一天的連續(xù)測(cè)試。測(cè)試結(jié)果如下：

聽云Server的產(chǎn)品在測(cè)試期間始終正常采集并展示數(shù)據(jù)

從測(cè)試的結(jié)果來看，聽云Server的探針和報(bào)表都比較穩(wěn)定，在一天的持續(xù)測(cè)試中，始終正常工作并且在報(bào)表上數(shù)據(jù)展示也是連續(xù)的。

四、結(jié)論

從這幾天的測(cè)試結(jié)果來看，聽云目前的產(chǎn)品還比較完善，除了個(gè)別小bug之外，基本可以達(dá)到在生產(chǎn)環(huán)境中使用的水平。后續(xù)會(huì)嘗試在生產(chǎn)環(huán)境中找?guī)讉€(gè)應(yīng)用節(jié)點(diǎn)部署試試，聽說聽云Server已經(jīng)公測(cè)了，大家可以去嘗試。