pagecache優化場景：使用者行為在多個熱點頁面中反覆切換。優化方式：基於quickling的流程，在客戶端做資料快取。優點：熱點頁面渲染快，服務端壓力下降。缺點：資料即時性問題。（當前可以模擬單客戶自己的操作行為，保證顯示及時性，但是如果服務端狀態變更，訊息無法通知，頁面資料較老）
思考：其實就是將可以快取的資料盡量快取，提高頁面渲染速度，過去切割頁面用ajax區域性渲染，現在整體都用ajax，本來的區域性渲染需要通過內部實現，但快取最大的問題就是狀態及時性，對於使用者資料顯示要求不高的可以用這種方式。（我的**頁面不可以用，及時性要求太強，雖然這是熱點頁面）。總體上來說還是多頁面的comet實現中快取的一部分。
延伸：服務端管道化模式中，可以考慮部分管道結果快取。簡單來說原來乙個請求乙個事務，現在被切割成多個小任務通過事件驅動的方式或者簡單的管道串聯的方式執行後，可以將某乙個環節的中間結果快取，那麼可以提高部分子任務的執行效率，在原來一條道走到黑的情況下做起來很複雜也很難看。
bigpipe優化場景：整體頁面可以被切割（無強依賴），每個切割塊之間可以並行被執行。優化方式：頁面切割為多個pagelet，交由ajax框架排程並行或者序列執行請求（當前主要使用序列化，通過區域性增量顯示，提公升使用者體驗）。優點：使用者體驗增強。
在開放平台服務請求中，我們的pipe支援演進和bigpipe很類似，如下四圖：
常規的web請求，容器負責業務執行緒的管理，業務請求直接在乙個service方法中完成。
還是常規的web容器，但是將乙個服務處理方法切割成多個pipe，包含三個部分，準備，執行，釋放，傳統任務被分割，不同子任務資源生命週期縮短，資源利用率提公升，如果採用lazy解析資料流，則可以更好的提公升上行頻寬的利用率，另一方面可以快取部分pipe的中間結果，提公升部分pipe的處理效能。
支援批量api請求和ql服務請求（前者是並行服務組合，後者是序列服務組合），容器執行公用的管道（消耗較低的管道），如果是ql call，則容器執行緒池順序執行多個api call，最後返回結果。如果是batch call，則啟動多個業務執行緒工作者，並行執行任務，隨機返回部分結果。好處就是減少連線損耗，合併多個請求共同處理的消耗。
其實很多優化理念看似簡單，但是作起來很多細節特別重要，就好比quickling如何用ajax模擬前進後退歷史，cache如何可選擇的部分監聽資料更新，bigpipe如何對不同客戶端請求或者爬蟲做支援。當然聽完分享更需要注意的是自己的場景如何借鑑。
Facebook優化分享後記
pagecache優化場景 使用者行為在多個熱點頁面中反覆切換。優化方式 基於quickling的流程，在客戶端做資料快取。優點 熱點頁面渲染快，服務端壓力下降。缺點 資料即時性問題。當前可以模擬單客戶自己的操作行為，保證顯示及時性，但是如果服務端狀態變更，訊息無法通知，頁面資料較老 思考 其實就是...
PHP效能全面優化分享
一 規範說明 效能是 執行是否良好的關鍵因素，的效能與效率影響著公司的運營成本及長遠發展，編寫出高質高效的 是我們每個開發人員必備的素質,也是我們良好的職業素養。二 影響效能的因素 a 商業需求 1.需求合理性 2.需求與系統的整合 3.需求所帶來的商業利益是否與需求開發的成本成正比 4.需求所帶來...
PHP效能全面優化分享
在上篇博文中分享了php的開發規範，這次給大家分享下在php開發中應該注意的一些關於影響最終 效能相關的開發規範。希望大家多多支援，相互交流完善。一 規範說明 效能是 執行是否良好的關鍵因素，的效能與效率影響著公司的運營成本及長遠發展，編寫出高質高效的 是我們每個開發人員必備的素質,也是我們良好的職...