關于PHP商城系統性能優化

? ? 最近在研究商城系統源碼，在想怎么去更好的優化，一般來說，性能優化可先從大的方向開始考慮，從對影響性能比較大的因素來考慮，比如現在使用PHP5.7，性能可以成倍提高，這些都是客觀因素，類似現在網上的開源商城，類似DSmall開源商城系統這類，基本都能支持高版本PHP，最后考慮的應該是PHP語法細節上。

1. PHP部署環境
   單臺服務器常用apache+php和nginx+php-fpm方式部署，我們一直使用apache+php方式，據說現在用nginx+php-fpm部署方式性能比apache+php性能好，可考慮一試。另外就是像nginx+swoole等，也是可選項。
   集群是在此基礎上，使用nginx/lvs/云上lbs等反向代理作為負載均衡前端。PHP集群部署在可靠性的基礎上，PHP集群處理性能比單臺服務器有N倍提高（但作為服務的整體性能并不一定有N倍提升）。所以簡單地可以認為，通過集群擴展服務器，可以使PHP服務性能得于提升。
   2.PHP擴展使用
   PHP擴展除了使用方便，還是提升性能的親密伙伴。主要應用有三點：
   1). 開啟opcode的緩存，來避免重復的編譯。可以使用APC,eAccelerator,XCache等PHP擴展，我們使用xcache。這種只要安裝即可的事。
   2). 使用擴展提供的方法（或PHP標準庫的方法），擴展實現的效率比PHP代碼中的高。但實際上滿足我們項目的擴展方法有限，很多基礎方法需要時一步封裝，除非有能力自己開發擴展。可考慮使用擴展實現的PHP框架，如phalcon、yaf。
   3). 本地緩存，也常用擴展來支持，比如xcache。本地可使用緩存擴展，緩存一些配置數據、元數據或主數據，不用每次都從數據庫或文件中讀取。
   另，PHP版本上，現在可以考慮升到PHP7……
2. 文件加載和操作
   這是非常重要的優化建議，盡量減少文件的讀寫，文件操作包括：文件讀、判斷文件是否存在、判斷文件大小，特別是對于磁盤，減少文件操作即減少尋道時間，讀取時間。減少一個文件操作，比優化N個CPU指令（request/request_once,echo/print,單引還是雙引）、內存的性能效果要好得多。
   實際應用中，關注以下幾個地方：
   1). 把.htaccess的內容寫到apache配置中。平時我們都是通過.htaccess作為文件放置到PHP項目的根目錄中，作為URL重寫配置等。這就造成每次HTTP請求，都要先讀取.htaccess，多了一次文件操作。通常.htaccess文件內容也不需要修改，因此可考慮在apache中配置，并禁用.htaccess文件。
   2). PHP程序中，減少file_exists等文件操作函數的使用。在路由框架中，判斷要引用的文件是否存在，如果不存在則顯示錯誤，存在則執行文件里的類方法。
   為什么不直接request $invoke ['path']呢？其實我們訪問的路徑（文件），正常的話都是存在的，所以沒必要使用file_exists判斷是否存在。但是訪問到不存在的文件怎么呢？用set_error_handler方式全局處理。但是我只想對當前引用文件錯誤做特殊處理，把錯誤處理留在自己的框架中，不使用用戶的全局的錯誤處理呢？
   在require前，重新設置一個錯誤處理方法A，并會返回之前設置的錯誤處理方法；當require文件不存在時，會執行A，require正常時，重新把用戶的error_handler設置回去。
   還有一個就是日志的處理，可能每次操作日志都要判斷一下日志是否存在（不存在即創建）和獲取日志大小（分隔日志文件），一般來說，日志文件存在的可能性大，所以直接獲取文件大小即可，通過獲取日志文件大小一個方法filesize，同時可判斷文件是否存在，不存在創建文件即可。這就減少一個文件操作方法的使用。如何使用filesize即可獲取大小，又可判斷文件是否存在，又不離開當前流程，正常執行下去呢？大家可以思考一下，因為filesize一個不存在的文件是會報錯誤的哦。
   總之，只要是文件存在的可能性或者命中率高，就可考慮不要使用file_exists。
   3). 類的加載中，使用精確加載并緩存，不要遍歷目錄文件的方式。如果在一個請求中，只加載且只加載一次需要的類文件是最好的。
   4). 將文件緩存轉成內存緩存。
3. 框架的選取
   除了上面說的PHP擴展框架，還有很多其它非擴展實現的PHP框架，像thinkphp,laravel，這些框架是通用的，封裝好、功能全，但自身會損耗一定的性能，主要原因我認為是加載的文件太多、定義的方法變量、檢測的東西太多、執行的流程太長。但既然用了，這個得接受，能做的是在語法細節、代碼邏輯上進行優化。僅就代碼執行（沒有外部調用，?數據庫連接等），框架的執行時間遠遠大于應用代碼執行時間，如果你還用上smarty模塊引擎，性能必大打折扣。但是除了性能上考慮，還有很多其它因素值得利用這些成熟框架的。如果覺得性能是要考慮的方面，可以選擇輕量一點、偶合性小的框架、或只選取需要的組件。
   5.功能組件的使用
   ? ? ?組合使用，需要對整個框架有一個認識和把控。
   1). 如果可以選用組件，第一個選擇的就是路由組件了，能方便地路由到指定控制器方法即可，不要做多余的事，少用正則匹配，約定優于配置。
   2). 類加載功能。上面說的，按需精確加載并緩存，一次請求有且只require一次。我們項目類的加載很原始，require_once and new。
   3). 參數校驗和安全處理。實際上這個也是相對耗費性能的過程，但為了安全還是有必要的。能做到按需參數處理最好，但是有時為方便，還是會在入口處全局處理安全過濾，參數校驗就可以在控制器方法中處理。
   4). session，簡單地通過配置保存到Redis/memcache等緩存中，或者存到cookie中。但是根據默認的機制，session初始化（讀取）和請求結束（寫回），會產生兩次網絡操作。根據我們應用場景分析，session內容是不常變的，在不變的情況下可考慮只讀而不寫回（因此也就有不能更新session修改時間 的問題），這就要自己實現PHP會話的接口了，只有當有session修改時，變更的時候才回寫session存儲，這樣，少一個網絡操作可省多少時間啊。有些實現得不好的，在一個請求中多次連接或多次操作存儲的，就不可取了。另外，結合cookieSession，即把session加密存到cookie中，對session的處理也會減少很多耗時。
   5). 視圖模板引擎。如果是API類接口服務，直接返回數據，如果是網頁，那就需要使用模板引擎了。模板引擎也是很耗費性能的主，當然，喜歡原生態的方式，那是最高效的，像smarty這種，大而全，性能低效，而且很多功能我們都用不上。我們使用模板引擎，最核心的是html與PHP分離，然后才是變量與語法的處理。所以，要享受模板引擎的分離好處，又追求性能，那可以參考tmd_tpl。只實現分離，語法上使用PHP語法，因為如果要自己實現一套語法，需要大量的查找和替換。同樣在模板引擎中，可以進一步合并多個視圖文件為一個，減少文件操作等方式來優化。
   6). 數據庫方面。使用PDO，ORM使用方便但也有一定耗時，數組作為數據對象最高效，一般用短連接，使用單例連接對象或連接池（有些擴展可支持）。