性能优化总结的一点回复

性能优化总结的一点回复

4. 全局观。优化后瓶颈转移带来的问题。

更快找到技术分享关键所在当然自己能力有限，  写这篇文章的目的希望能够分享给一些处于技术上升阶段的同学。有些内容也就自己根据自己实际情况来思考）

都有同学问我能说清楚技术这件事情是自己天生的能力还是后天培养的如果是后天培养的那么靠什么方式提升自己。把技术人员生长分了个类： 1. 会解决问题的 2. 会分析问题的 3. 会总结问题的 4. 会深化思考的 5. 会分享的        记得这两届淘宝技术大学分享的时候。

不管是否有有效手段，        最基本的就是解决问题。只要解决问题就算完事。慢慢的会解决问题的人会考虑更多，会去分析根源，不会头痛医头，脚痛医脚，那就开始分析问题，渐渐的解决问题之前会先分析，动手，做完以后写下前因后果。当遇到问题多了分析也多了就会总结规律，防范与未然。再后来就会从点到面，不再简单等待面的发生，学会深化思考，从现象看到实质。最后就是融会贯通，印在脑子里，而不是写在纸上，能够分享给更多的人。

 

一种是满眼都是字，      技术人员的 PPT 也分成两种。另一种是简单的几行字，一些图，原因是什么，很简单，如果不是融会贯通印在脑子里，那么生怕自己忘了能在 PPT 上写多少是多少，不会临场忘记。而真正让听众感觉最真实最自然的方式，应该是分享者出自自己的下意识说的话，随时随地可以插入范例。

PPT 很有技术含量（ http://www.slideshare.net/cenwenchu/ss-5036757 另外会转推一下。

总的问题：      后面是回复的一点内容。

有分析，    有现象。缺少最后一铲子的挖掘，同时描述问题和解决的同时，最好先阐述本质，以免使得阅读者走向特定场景的分析，对于了解实质可能发生误导。

cpu 只是这一个应用的瓶颈，   1. 最佳线程数从 cpu 角度去描述容易引起误导。计算最佳资源利用率应该从更通用的方式去说明，同时提到最佳线程自身来说就是依据环境变化而变化，其实也就是说明了实质其实隐藏在其后。

但是需要梳理出关键路径消耗时间来看各个阶段消耗时间，   2. 测试是一方面。及评判系统消耗和业务消耗的比例，分析出关键路径的性能瓶颈和消耗所在不然可能要走不少弯路，同时提到过瓶颈转移的问题会导致优化与预期的不符，总的来说要从全局去考虑优化，而不是局部系统。判断系统消耗和业务消耗比例应该不是很精确，但是大致可以找到瓶颈在某一方）

可以把 cpu 也看做有一个线程池，   3.IO 和 CPU 优化提升 QPS 这件事情觉得举例没有说到重点。 IO 有一个线程池， web 容器有一个线程池，由于现在阻塞式处理，那么处置能力就取决于最小的线程池资源和整体处置时间，当前最小线程池出现在 cpu 因此 cpu 处置时间缩短使得资源生命周期变短，资源利用率提高，并发处置能力提升。

  4. 没有极端应用的说法：可以参看 1 2 3

但是结合一些正反例子就能够把问题根源说清楚） 下面是感觉优化在看来最根本的点（当然这个直接给被分享者看不适合。

影响 TPS QPS 关键指标：

响应时间（ RT 资源

优化手段：

降低 RT 增加资源就是提升 TPS 根本。 简单来说。

1. 入口。解决问题一般总是从降低 RT 开始。

2. 抵触。增加资源的时候引起 RT 上升（例如增加压力导致依赖系统处置性能下降）

就会考虑通过增加资源来缓解问题（前提是不会增加 RT 3. 权衡。但当降低 RT 会增加系统复杂度和稳定性的时候。