對於這個問題首先我們要知道影響php的性能的原因是什麼？也就是
1 什麼情況下會出現php性能問題？
１ｐｈｐ語法使用不當（包括某些業務可以使用php 本身自帶的函數來處理）
２使用ｐｈｐ語言做了它不擅長的事
３用ｐｈｐ語言鏈接的服務器不給力（當然如果是localhost也就是你本地配置比較差哈，建議換本吧，哈哈）
４ｐｈｐ自身的短板 （PHP 自身就做不了）
５我們也不知道的問題 （囧）
2 php 性能問題簡介之php的性能問題的解決方向
從困難度由淺到深分別為：
1 Php 語言級的性能優化
2 Php 周邊問題的性能優化 （比如說mysql nginx|apache）
3 Php 語言資深分析，優化（ps 主要指的是底層的c代碼）
下面針對php語言級的性能優化做實例討論，對標題裡面說的內容進行一個測試，接下來要書寫兩個文件 bad.php, goods.php
我們要測試的是合並兩個數組的操作（測試工具 apache ab test）
bad.php
思路：
先將數組1逐個加入到目標數組中；
之後，遍歷數組2，對比數組2的元素是否在數組1中出現，如果沒有則插入到目標數組，否則忽略掉
goods.php
思路：
隨機生成兩個數組，在打亂順序
之後，使用array_merge 合並
3 使用 ab 測試兩個php腳本的速度：（ps:驚人的時刻開始了）
bad.php
goods.php<喎?http://www.Bkjia.com/kf/ware/vc/" target="_blank" class="keylink">vcD4KPHA+PGltZyBzcmM9"http://www.2cto.com/uploadfile/Collfiles/20141205/20141205084010231.png" alt="">
對於這兩個測試，我們明顯的看出這的差的不是一點半點啊，在執行bad.php 的時候我明顯的感覺電腦的風扇翁的一下，你懂得！
bad.php 每秒響應174個請求， 每個請求處理572ms
goods.php 每秒響應4050個請求， 每個請求處理24ms
ps: 如果還要小伙伴在使用bad的寫法，趕快改掉它，小心不要你的領導知道哦！
4 究其原因對於這個結果我也很吃驚，但是事實就在眼前，沒辦法啊，那麼到底為什麼會有這樣的效果呢，咱們繼續一探究竟：
*.php(php代碼) -----Scanner（zend引擎逐行掃描變為zend可以識別的語法）----> exprs
-----parser(解析為opcode)-----> opcodes ------exec(執行最後輸出)-------> output
可以知道 一個php文件執行zend需要先掃描，然後解析為opcode 在執行輸出，問題就出在這裡，當我們使用php自身的函數的時候其實他就屬於zend 引擎，所以zend 解析起來就比較順手，速度那叫個快（goods.php）, 但是當執行bad.php 的時候就會比較慢，因為讀別人寫的代碼肯定沒有讀自己寫的代碼快大家說對吧，所以還是使用原創，不要自己造輪子比較好啊！
多說一點，這也就是為什麼現在好些Php擴展（比如 apc）都來緩存opcode 因為這樣就少了掃描與解析的環節，那肯定是快了！
5 總結
優化點：少寫代碼，多用php自身提供的能力
性能問題：
自己寫的代碼冗余較多，可讀性不好，並且性能低
為什麼性能低？
php代碼需要編譯解析為底層語言， 這一過程每次請求都會 處理一遍，開銷大。
好方法：
多使用php內置變量，常量， 函數（spl 可以帶給您好像好用的功能）
