一、吞吐量与响应时间

系统的吞吐量反映了一个系统的容量，可承受的负载，很多系统都以这样一个指标来衡量系统的性能。而响应时间往往更容易忽视。我认为吞吐量更多是衡量一个系统在特定压力下的稳定性，而响应时间可以更好的形容系统性能。一个请求响应时间满足不了需求，那系统再高的吞吐量是没有意义的。比如普通的网站页面，如果客户的一个请求都能在200ms以内响应，那是非常不错，如果能在2秒内响应，那也还行，但如果都要在20秒响应，估计没人使用。而对于局域网内的应用，如营业厅收费操作，这种响应时间如果是2秒都会让营业员有明显的不爽。

二、忽视系统环境差异

我们是否经常出现线下性能测试非常好，线上性能很差问题，或者是A环境好，B环境性能差。这种情况大部份是系统环境的差异，如两个环境硬件不一样，配置参数不一样，数据规模不一样，缓存命中率不一样等等。在做性能测试时需要深入分析正式环境的各种数据细节，然后在做性能测试时有针对性的去模拟。

三、性能测试无用论

性能测试是一个非常复杂的工作，也是考验人计算机功底的工作，性能测试并不仅是学习如何使用loadrunner或jmeter之类的工具，更多是要分析用户及业务场景，估算并验证系统性能容量，找出性能瓶颈并解决。精通测试工具可以更好的提高工作效率。之所以有些人会提出性能测试无用论，大部份因为他认为正式环境太复杂，无法有效模拟出正式环境的瓶颈。其实这也是性能测试的难点，如何在不同的环境中模拟出性能瓶颈。如果是普通测试工程师，估计只会根据业务逻辑搭建性能测试环境，并给出测试结果。如果是高级测试工程师应该清楚系统架构、应用逻辑、业务场景、数据分布、硬件性能等等，后给出有意义的性能测试模拟场景和数据。

性能测试容易忽视的是数据分布与缓存命中率。正式环境的数据分布可以通过线上数据抽样，没有正式数据只能根据业务评估。比如工作流应用中个人平均待办工单是多少？电子商务应用中热销商品的评价记录会有多少？这些数据分布对性能测试的结果有非常大的影响。

缓存命中率对性能测试结果的影响更恐怖，可能有10倍，甚至上万倍都不为过。常用如CPU cache对内存的缓存，内存对硬盘的数据缓存，memcached对db数据的缓存，浏览器本地对远程的缓存。我们做性能测试需要仔细分析正式的缓存命中数据，然后模拟差值、正常值、好值去评测，后分析出缓存命中率对真实性能的影响。

四、缺少性能量化

性能量化是指对系统功能或硬件的主要指标进行性能指标计算，比如一个查询请求的所有开销计算，包括网络开销，应用服务器开销，数据库服务器开销等等，或者是更细化的CPU开销，内存开销，IO开销等。性能量化还包括系统所使用的硬件指标，包括CPU性能，内存容量及性能，硬盘带宽及IOPS，网络带宽及延时等等。没有这些基础数据是很难做性能量化，否则只能做简单的表面性能测试，给出一些感性数据，准确的系统整体性能容量评估也无从谈起。没有扎实的性能量化基础数据，搞不清楚一个逻辑在各个环节开销，那做性能优化只能是凭感觉或经验走。

五、硬件成本

在IT人的眼里硬件的费用是很高的，软件成本是很低的甚至可以忽略，因为硬件需要购买，基本上没有免费的硬件，而软件可以选择开源免费的，或者自己开发，甚至使用盗版。因此在遇到性能问题是程序员首先想到的优化软件性能。但在这个人工成本上升，硬件成本下降，硬件性能或容量随摩尔定率的发展的时代，我们也应该重视硬件的优化方法。

如果是服务器网络瓶颈，百兆接口升级到千兆，千兆升级到多口千兆甚至是万兆，这种升级都可以快速解决性能问题。单块SATA硬盘吞吐量不够，可以选择换SAS 15K硬盘，吞吐量提升1倍，如果还不够可以选择多块硬盘做RAID，实现一个数量级内近线性的吞吐量提升，如果是硬盘IOPS低，可以选择换SATA的SSD硬盘，能提升10倍以上的IOPS，如果要求更高可以选择换PCIe的SSD硬盘，可以提升100倍以上的IOPS。内存不足可以增加内存容量，当前单根4G，8G容量的内存性价比都不错。CPU升级一般比较麻烦，因为受到CPU架构的影响，且CPU的发展较快，成本较高，所以很少做，对于老的服务器CPU不足一般会选择直接淘汰，重新采购新的。

通过硬件升级可以快速解决系统性能问题，对于可预估的系统容量性价很好。但顶配或者新出来的硬件贵得离谱，新的硬件往往也会存在一些未知的BUG，所以硬件升级一般不会选择1年内出来的全新架构的设备，而通常选择2年以上比较成熟的硬件性价比会更好。但是硬件升级往往会有上限，顶配或者高性能的硬件往往性价比不好，所以在硬件升级解决问题后同时需要分析业务增长导致更多硬件成本的问题。选择软件优化还是硬件优化是一种技术成本平衡决策，有时软件也需要针对硬件做特定的优化。

六、缓存的威力

缓存是好东西，基本上90%的系统架构优化都是在围绕着如何利用好缓存。缓存真是无处不在，硬件上看，有硬盘缓存，RAID卡缓存，存储缓存，主存，NUMA特性，CPU L3-L2-L1等等。软件架构上看，有全局数据缓存，私有数据缓存，连接池，应用服务器缓存，WEB服务器缓存，CDN缓存，客户端文件缓存，客户端内存缓存等等。基本上大型系统都会有很多级缓存，否则需要非常高的硬件投入才能解决问题。硬件缓存通常都比较智能，或者说99%的情况下我们不需要修改配置，即使修改带来的性能提升一般也不会太多，除非你的软件有较明显的缺陷，你对硬件和你的软件特性已经了解得非常深入。 软件缓存架构带来性能的提高，往往也带来了负面的问题，如架构复杂化，数据同步多，数据不实时，维护成本高，系统调试复杂等问题，所以对于软件架构上任何一个缓存架构，都需要深入分析是否有必要。我认为如果增加一层缓存架构，至少要有5倍以上的提高提升，否则要分析成本了。 对于中小型系统，不建议有复杂的缓存架构，因为让系统能更快速发展比提供更好的性能更有意义，杂的缓存架构往往需要投入更多的人力成本。

七、客户第一

我不知道客户第一是谁提出来的，但这个词真不能从字面上去理解，否则会让我们走向歪路。首先，谁是我们的客户，谁是我们的直接客户，谁是我们的终客户，付钱给我们的是否是我们的客户？客户类型1与客户类型2发生了利益冲突，我们该以谁为第一。重要的客户与大部份客户利益有冲突时如何处理。这些看似与系统性能优化无关的话题，但往往左右我们系统设计的方方面面。我们做的工作有没有为了个别客户去优化他的界面流程或性能而让大部份用户认为系统更复杂或更难使用。

八、过度优化

大家都清楚性能优化的重要性，因此我们很多经历都是在做系统优化，也导致我们有时会犯过度优化的错误。有人说他性能优化提高了10倍，100倍，1000倍，但我们有时并不需要这种做法，这种事情更多是自己在优化技能上的一个学习。我们在做优化时应该多问一些问题 ：你的优化让系统有什么变化：

你的优化有没有让系统更复杂了，以后的维护成本高了一些？

你的优化是否对大部份业务场景有效，还是只是为了一小部份场景优化而让其它主业务变慢或变复杂了？

你的优化对客户体验有感觉吗？

你的优化方法可持续有效吗，还是业务逻辑稍有变化失效了？

......

我认为系统优化一定要有一个目标，而不是一味的提高性能，因为在性能优化的背后一定会带来或多或少的系统复杂度。系统性能优化在满足需求的情况下，需要开始衡量是否会让系统架构扩展性更差，或系统稳定性变差，可维护性变差等问题。