性能優化-開發流程中的性能優化

性能優化不是某一我的的職責範圍，也不是某一個開發階段的工做內容，而應該是貫穿整個開發流程、每一個人員都參與的活動。若是等到項目上線後再進行優化，會致使咱們成爲需求
的被動接受者。爲了不這種狀況，咱們應該主動出擊，在項目初始階段就將性能問題融入進去。

需求討論階段

開發人員分析實現方案，提出建議，在不影響產品目的的前提下，引導產品經理對需求作一些調整以獲取更高的性能。
好比對於產品經理提出的一些實時性統計，能夠酌情修改成準實時統計，將緩存利用起來；
對於初始就須要返回大量數據的頁面，能夠適當調整需求，減小數據量。

方案設計階段

明確產品業務架構，挖掘潛在風險點；注重動靜數據的分離，利用好緩存；根據不一樣的項目類型，選擇合適的技術。
好比須要開機啓動的頁面(咱們的頁面是嵌入在公司的客戶端內部的)，那麼儘可能靜態化或者採用其餘支持大併發的部門的存儲方案來實現(咱們部門由於資源問題，對於大併發支持得還不是很好)；
頁面數據能夠拆分的，只在首次請求中返回靜態的緩存數據，而後經過異步加載的方式獲取剩餘的動態數據；
針對併發量大的內容，可用採用HandlerSocket、主從等支持高併發的方案。

前端模板製做階段

對樣式進行分類，利用CSS Sprite技術，將小圖片，特別是一些圖標類的圖片，整合到一塊兒，減小其數量。
特別是針對長期項目，隨着後續需求的增長和修改，樣式圖片、樣式文件的數量會大量增長。這是影響頁面性能的一大因素，由於一方面這些資源太分散，會致使請求數增多；
另外一方面這些東西大都是和頁面可見性息息相關的，請求過慢會致使頁面樣式錯亂。所以能夠在模板製做階段，和前端同事溝通，對圖片、樣式文件作分類，而後進行合併。

代碼編寫階段

遵循一致的代碼編寫規範，互相codereview，同時藉助工具進行代碼性能分析，避免代碼級別的性能問題。
目前統一採用Zend編碼規範，而且有PHPMD工具會對代碼進行靜態掃描，發送郵件通知開發人員；
同時在測試環境和部分產品的正式環境部署了XHProf，用於代碼性能的分析。經過這兩個工具，能夠排查代碼中的邏輯嵌套過深、函數誤用、遞歸等問題。
另外在代碼編寫完成後，必定要記得將圖片、樣式文件、JS腳本文件壓縮整合後，上傳到公司專門的資源服務器上。
一方面是由於資源服務器採用了和產品服務器不一樣的主機名，可以增長瀏覽器對資源的並行下載數；另外資源服務器上的文件都作了緩存，也能加快用戶二次訪問的速度。
切忌在正式產品中使用本地圖片和腳本資源。

測試階段

對於有併發量要求的接口和頁面進行壓力測試。
對於有併發要求的頁面和接口作一個預估，而後主要採用JMeter進行併發測試，保證在預估值之上必定充分餘量的狀況下，頁面或接口仍能正常使用。

上線後

經過線上日誌數據，獲取產品的正式表現，進行後續優化。
經過各類日誌(Nginx日誌、Mysql慢日誌、XHProf日誌等等)，分析線上環境和測試環境之間差別致使的性能問題，經過用戶端的真實數據來肯定優化點，而後按照緊急重要程度進行優化。