一、問題背景

一位同事反饋我們的一個接口每次返回需要5秒之久，我們一起review了代碼，“驚喜”的發現居然在循環(大約900次)中調用了一個讀緩存的操作，而這個緩存的key并沒有改變，因此我們把這段代碼移到了循環外面，再測，接口返回時間降到了2秒，嗚呼！雖然提升了1倍，但明顯不是我們能接受的結果！

出現性能問題的代碼量并不大，我們排除了IO問題以后，寫了一段測試代碼，果然問題很快重現。

< ?php

$y="1800";

$x = array();

for($j=0;$j<2000;$j++){

$x[]= "{$j}";

}

for($i=0;$i<3000;$i++){

if(in_array($y,$x)){

continue;

}

}

?>

執行結果如下：

shell$ time /usr/local/php/bin/php test.php

real0m1.132s

user0m1.118s

sys0m0.015s

對的，我們用的就是字符串型的數字，從緩存拿出來就是這樣子的啦！所以這里是特意轉成字符串的(如果直接是數字，并不會出現這個問題 ，各位可以自行驗證)。可以看出時間耗掉了1秒，才3000次循環,后面的sys用時也注定我們用strace不會拿到什么有效信息。

二、過程分析

1、strace工具分析

shell$ strace -ttt -o xxx /usr/local/php/bin/php test.php

shell$ less xxx

具體執行結果見下圖：

可以看出上面從3515到3519這中間執行兩次系統調用的時延非常大，卻并不知道干了什么？一籌莫展了，幸好，Linux下的調試利器除了strace還有ltrace(當然還有dtrace，ptrace，不在本文討論范圍了，略去)。

引用：strace用來 跟蹤一個進程的系統調用或信號產生的情況，而 ltrace用來 跟蹤進程調用庫函數的情況(viaIBM developerworks)。

為了排除干擾因素，我們將$x直接賦值為array(“0″,”1″,”2”,……)的形式，避免過多的malloc調用影響結果。執行

shell$ ltrace -c /usr/local/php/bin/php test.php

如下圖：

2、ltrace分析

我們看到庫函數__strtol_internal的調用非常之頻繁，達到了94%，太夸張了，然后我又查了一下這個庫函數__strtol_internal是干嘛的，原來是strtol的別名，簡單的說就是把字符串轉換成長整形，可以猜測PHP引擎已經檢測到這是一個字符串型的數字，所以期望將他們轉換成長整型來比較，這個轉換過程中消耗了太多時間，我們再次執行:

shell$ ltrace -e "__strtol_internal" /usr/local/php/bin/php test.php

可以輕松抓到大量下圖這樣的調用，到此，問題找到了，in_array這種松比較，會將兩個字符型數字串先轉換為長整型再進行比較，卻不知性能就耗在這上面了。

知道了癥結所在，我們解決的辦法就很多了，最簡單的就是為in_array加第三個參數為true，即變為嚴格比較，同時還要比較類型，這樣避免了PHP自作聰明的轉換類型，跑起來果然快多了，代碼如下：

$y="1800";

$x = array();

for($j=0;$j<2000;$j++){

$x[]= "{$j}";

}

for($i=0;$i<3000;$i++){

if(in_array($y,$x,true)){

continue;

}

}

?>

執行結果如下；

shell$ time /usr/local/php/bin/php test.php

real0m0.267s

user0m0.247s

sys0m0.020s

快了好多倍啊！！！可以看到sys耗時幾乎沒有太大變化。我們再次ltrace一把，還是要把$x直接賦值，排除malloc調用的干擾，因為我們實際應用中是從緩存里一次拉出來的，所以也不存在示例代碼中這樣的循環來申請內存的情況。

再次執行

shell$ ltrace -c /usr/local/php/bin/php test.php

__ctype_tolower_loc占用了最多的時間！查了一下庫函數__ctype_tolower_loc是干嘛的：簡單的理解是將字符串轉換成小寫，那么這說明in_array比較字符串不區分大小寫嗎？其實這個函數調用已經和我們這個in_array感覺聯系不大了，關于in_array的實現，還是去看看PHP的源碼，大概理解的更為透徹了。

三、其他

晚上又翻了以下PHP 5.4.10的源碼，對in_array的興趣真大啊，哈哈，位于./ext/standard/array.c的第1248行，可以看到他調用了php_search_array函數，下面的array_serach也是調的這個，只是最后一個參數不同！經過一番跟蹤，在in_array松比較的情況下，他最終調用的函數 zendi_smart_strcmp(果然是個“聰明”函數)進行比較，位于./Zend/zend_operators.c，我們用ltrace抓到的大量轉換成整型的操作就是那個is_numeric_string_ex的行為。

函數is_numeric_string_ex是在./Zend/zend_operators.h中定義的，在前面進行了一堆的判斷和轉換之后，在232行調用了strtol，就是我們在文章中提到的系統函數了，將字符串轉換成長整型，有圖有真相

本文來自于zendstudio 遭遇php的in_array低性能 ，與原文略做修改。因為近期在查看RH442的教材，看到關于strace與ltrace相關的調優工具，感覺這個示例非常不錯。這里就摘錄下做個備案。加深對這些工具的理解。

總結

以上是生活随笔為你收集整理的php trace 图形,trace工具定位php性能问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。