认清性能问题
最近几天详细的阅读了一篇经典的关于软件性能的文章，阅后解答了我不少迷惑，这篇博客就把本身阅读后的一些思考和总结分享一下，若有不能理解或想阅览具体内容的请参考原文和译文内容。。。。性能优化
原文地址：Thinking Clearly About Performance多线程
译文下载连接：认清性能问题并发
一、响应时间VS吞吐量负载均衡
一般来讲，响应时间和吞吐量承反比例（响应时间越长吞吐量越低）。性能
PS：博客发布后测试群的一个大神说第一点存在描述问题，因而咱们就这一点聊了些相关的话题，大概的内容和结论是这样的：测试
①、响应时间和吞吐量并无直接的关系（可是有间接关系）；优化
②、性能优化是须要多维度去衡量和优化的领域；spa
③、通常来讲，性能优化的目标是：在尽可能保持和下降响应时间的状况下，不断提升吞吐量，提升流量高峰时间的系统服务可用性（大多数状况，而非所有）；线程
④、响应时间、吞吐量、可用性等因素有时候存在矛盾，须要综合考虑业务状况、系统模块的依赖关系、处理方式（单线程/多线程/负载均衡）等因素，作到合理取舍；orm
二、描述响应时间的方式
尽可能用百分比的方式而非平均值来描述响应时间！————用户感知到的是差别变化，而非平均！
三、性能需求指标
性能需求指标应该是明确描述的、可量化的指标需求。
四、性能剖析思路
找到最慢的几个任务（消耗时间最多），分析它们是否有对应关系，每一个任务的时间占比，获得一个明确的描述：每一个任务运行消耗了多少时间！
五、阿姆达尔定律
系统对某一部件采用更快执行方式所能得到的系统性能提高程度，取决于这种执行方式被使用的频率，或所占总执行时间的比例。
六、性能优化排序
优先占用资源最多或消耗时间最多的任务，但要考虑优化的成本、收益、风险（没有最好的方案，只有最合适的方案）。
七、偏斜度
表示在一组响应时间值中的非一致性程度（好比下面两组值的对比）
①、表现值和实际值
②、平均响应时间和95%响应时间
八、最小化风险
确认问题根节点，不要让局部影响到全局。
九、提高效率
性能优化优先原则：首先专一于业务上最须要优先修正的程序，而不是从全局调优来改善性能。
十、负载
负载的一个直观测量指标：使用率（反映了资源按时间分片的使用状况）；
负载会在并发任务执行时引起资源竞争；
引发负载上升系统变慢的2个缘由：队列延迟和相关性延迟（资源竞争，等待，死锁等）
十一、响应时间
特色：在具有完美扩展性的前提下：RT=servertime（任务执行时间）+querywaittime（队列等待时间）
十二、拐点
响应时间和吞吐量之间的某个最优负载平衡点的资源使用率的值，称为拐点。
计算公式：响应时间/资源利用率=所得结果最小的值
1三、拐点相关性
在完美扩展性前提下，只要系统的平均负载超过拐点，那么系统依然会面临性能瓶颈，实际生产中的拐点比上图的拐点数值更小。
拐点主要有如下几个特色：
①、系统中的每一项资源都存在拐点；
②、系统的拐点都≤上图中给出的值，系统的扩展完美型越差，拐点越小；
③、对于请求随机到达的系统，若是资源负载持续超过拐点，那么将遇到性能瓶颈；
1四、随机到达
随机任务请求每每会汇集等待并引起短暂的资源使用率上升，须要足够的容量来消费。这种状况下可能会引起队列延迟并致使响应时间的明显波动。（等待时间参考：2/5/8原则）
1五、容量规划
容量规划特色：
①、某项资源的容量就是高峰期能够轻松运行任务而资源使用率不会超过拐点的值；
②、保持资源利用率低于拐点，系统表现则基本不会低于咱们的指望值；
③、若是系统中某项资源超过它的拐点，就会遇到性能瓶颈；
④、遇到容量瓶颈，解决方式是：从新配置负载分配（减小负载OR增长容量）；
关于这篇文章，最后说起到了一个很明确的观点：过早的考虑优化系统性能，是一场灾难！！！