写这篇文章的目的是希望能够分享给一些处于技术上升阶段的同学，更快找到技术分享关键所在。（当然自己能力有限，有些内容也就自己根据自己实际情况来思考）
记得这两届淘宝技术大学分享的时候，都有同学问我，能说清楚技术这件事情是自己天生的能力还是后天培养的，如果是后天培养的，那么靠什么方式提升自己。我把技术人员成长分了个类：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.降低资源池资源生命周期，提升回收率。（事件驱动就是很好的模式，将生命周期切割为更小片段，有状态线程生命周期越短，处理能力越强。副作用：系统复杂）
最后还是自己在做异步化的最大感受，一定要有全局观，系统内部全局观，系统之间的全局观，优化是对用户体验的优化而不是系统的优化。