寫這篇文章的目的是希望能夠分享給一些處于技術上升階段的同學，更快找到技術分享關鍵所在。（當然自己能力有限，有些內容也就自己根據自己實際情況來思考）
記得這兩屆淘寶技術大學分享的時候，都有同學問我，能說清楚技術這件事情是自己天生的能力還是后天培養的，如果是后天培養的，那么靠什么方式提升自己。我把技術人員成長分了個類：1.會解決問題的。2.會分析問題的。3.會總結問題的。4.會深化思考的。5.會分享的。
最基本的就是解決問題，不論是否有有效手段，只要解決問題就算完事。慢慢的，會解決問題的人會考慮更多，會去分析根源，不會頭痛醫頭，腳痛醫腳，那就開始分析問題，漸漸的解決問題之前會先分析，在動手，做完以后寫下前因后果。當遇到問題多了，分析也多了，就會總結規律，防范與未然。再后來就會從點到面，不再簡單等待面的產生，學會深化思考，從現象看到本質。最后就是融會貫通，印在腦子里，而不是寫在紙上，能夠分享給更多的人。
技術人員的PPT也分成兩種，一種是滿眼都是字，另一種是簡單的幾行字，一些圖，原因是什么，很簡單，如果不是融會貫通印在腦子里，那么生怕自己忘了，能在PPT上寫多少是多少，不會臨場忘記。而真正讓聽眾感覺最真實最自然的方式，應該是分享者出自自己的下意識說的話，隨時隨地可以插入范例。
后面是我回復的一點內容，首先，這個PPT絕對是很有技術分量的PPT，只是差臨門一腳^_^。具體的PPT（http://www.slideshare.net/cenwenchu/ss-5036757）
總的問題：
有現象，有分析，缺少最后一鏟子的挖掘，同時描述問題和解決的同時，最好先闡述本質，以免使得閱讀者走向特定場景的分析，對于了解本質可能產生誤導。
1.最佳線程數從cpu的角度去描述容易引起誤導，cpu只是這一個應用的瓶頸，計算最佳資源利用率應該從更通用的方式去說明，同時提到最佳線程本身來說就是依據環境變化而變化，其實也就是說明了本質其實隱藏在其后。
2.測試是一方面，但是需要梳理出關鍵路徑消耗時間來看各個階段消耗時間，及評判系統消耗和業務消耗的比例，分析出關鍵路徑的性能瓶頸和消耗所在，不然可能要走不少彎路，同時提到過瓶頸轉移的問題會導致優化與預期的不符，總的來說要從全局去考慮優化，而不是局部系統。（判斷系統消耗和業務消耗比例應該不是很精確，但是大致可以找到瓶頸在某一方）
3.IO和CPU優化提升QPS這件事情覺得舉例沒有說到重點，你可以把cpu也看做有一個線程池，IO有一個線程池，web容器有一個線程池，由于現在是阻塞式處理，那么處理能力就取決于最小的線程池資源和整體處理時間，當前最小線程池出現在cpu，因此cpu的處理時間縮短使得資源生命周期變短，資源利用率提高，并發處理能力提升。
4.沒有極端應用的說法：），可以參看1，2，3
下面是我感覺優化在我看來最根本的點（當然這個直接給被分享者看不適合，但是結合一些正反例子就能夠把問題根源說清楚）
影響TPS(QPS)的關鍵指標：
響應時間（RT），資源
優化手段：
簡單來說，降低RT，增加資源就是提升TPS的根本。
1.入口。解決問題一般總是從降低RT開始。
2.沖突。在增加資源的時候引起RT的上升（例如增加壓力導致依賴系統處理性能下降）
3.權衡。但當降低RT會增加系統復雜度和穩定性的時候，就會考慮通過增加資源來緩解問題（前提是不會增加RT）。
4.全局觀。優化后瓶頸轉移帶來的問題。
影響RT的關鍵指標：
1.關鍵路徑事務處理時間。（并行化和串行化可部分解決關鍵路徑時間長短問題）
2.瓶頸查找（資源池的瓶頸在哪里，處理時間消耗環節在哪里）
a.cpu,memory,io,jvm等系統級別影響RT的因素定位。
b.業務關鍵路徑中可提升的step。
c.優化后瓶頸可能轉移的考慮，整體上可能導致RT時間反而增加。
d.降低資源池資源生命周期，提升回收率。（事件驅動就是很好的模式，將生命周期切割為更小片段，有狀態線程生命周期越短，處理能力越強。副作用：系統復雜）
最后還是自己在做異步化的最大感受，一定要有全局觀，系統內部全局觀，系統之間的全局觀，優化是對用戶體驗的優化而不是系統的優化。