性能瓶颈，大的方面

1，硬件，服务器数量，

主要指的是CPU、RAM方面的问题。

  • 例如，
    在进行软件需求分析、概要设计时，确定了在数据库服务器上需要6个CPU、12G内存，但是在测试时，发现CPU的持续利用率超过95%，这时可以认为在硬件上出现了性能瓶颈。
  • 怎么办？
    加服务器

2，操作系统

一般指的是Windows、Unix、Linux这些操作系统。

  • 例如，
    在windows系统中，虚拟内存设置的不合理，都指定为C驱提供虚拟内存，在测试时发现当出现物理内存不足时，虚拟内存的交换效果非常不理想，导致交易的响应时间大大增加。这时可以认为在操作系统上出现了性能瓶颈。
  • 怎么办？
    这个要运维操作了，调整操作系统

3，网络设备，带宽上的，

一般指的是防火墙、动态负载均衡器、交换机等设备。

  • 例如，
    在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其它负载较轻的应用服务器上。
    在测试时发现，动态负载均衡机制没有起到相应的作用， 这时可以认为在网络设备上出现了性能瓶颈。
  • 怎么办？
    调整网络

4，应用软件

一般指的是应用服务器、WEB服务器等应用软件，还包括数据库系统。

  • 例如，
    在WEBLogic平台上配置了JDBC连接池的参数，最大连接数为50，最小连接数为5，增加量为10。
    在测试时发现，当负载增加时，现有的连接数不足，系统会动态生成10个新的连接数，这样导致了交易处理的响应时间大大的增加。这时可以认为在应用软件上出现了性能瓶颈。
  • 怎么办？
    也包括一些中间件

5，应用程序，就是代码层面

一般指的是开发人员新开发出来的应用程序。

有几个细分的方面

架构

系统架构肯定是第一个要关心的。很多其他涉及性能的问题，都会因为架构原因导致无法优化。哈。

架构不单单针对大系统，小系统，例如计算量高的，数据流向的合理设计，也是个架构问题。想充分发挥硬件资源，同样也是架构问题。

影响性能瓶颈的最大因素是系统架构，其次才是代码质量，操作系统和网络环境这些都是次要的，因为变化操作系统和提升网络环境都相对简单很多。

------ 很明显，这个才是主流的性能瓶颈的观点，

模块

模块的优化，确实涉及语言和具体程序代码质量问题。这块要看预期和实际的差异。理论分析得到的性能指标总是达不到，那么代码确实有的要调整了。。

  • 代码，例如：
    某个开发员开发了一个缴费处理程序，在测试时发现，
    这个缴费处理程序在处理用户发过来的并发缴费请求时，只能串行处理，无法并行处理，导致缴费交易的处理响应时间非常长，这时可以认为在应用程序上出现了性能瓶颈。
  • sql
    性能瓶颈？？低端公司全是SQL上，中端公司全是SQL。大型公司才是架构上

ps

当然架构没问题，各模块优化已经到位，仍然出现不符合设计预期的情况，这多半要改底层硬件了。其实加内存不也是改硬件的一项工作嘛。哈。

  • 怎么办？
    这是最需要关注的，重点关注的，
1，访问量大的地方，比如首页，这种访问量大，
方案，可以做缓存，查询优化，其他高端的操作，分布式

2，数据量大的地方，比如报表，导出，列表页，百万级，千万级的数据量，
进行分页，数据查询优化，

3，批量操作的地方，这种会产生人为并发的地方，
控制批量操作的数量，一页就可以了，

4，架构上的问题，代码设计的问题，

总结

个人觉得项目性能瓶颈，不外乎三个大因素

程序代码
操作系统
网络环境

如果想要解决瓶颈，那么应该先定位瓶颈的位置究竟是在哪一点，或者是哪几点。可以先从简单到复杂开始排查：

上诉三大因素，最简单的就是网络环境了，一句话，如果带宽没爆/延时，抖动什么都没问题，那么你的网络都不是瓶颈。如果带宽一下子就爆了，先判断这个流量是不是正常的，不是程序bug导致的哈，那么咱们需要加大带宽或者解决了网络环境暴露出来的问题等等，如果在处理之后，我们发现程序跑的更好了，那么可以暂时评估是网络环境造成，

如果网络环境没问题，就来判断系统方面。系统方面的关注点不外乎就是：操作系统类型，内核版本，内存，cpu，磁盘IO，文件数，并发数等等。其实这些指标的标准没有一个固定的值。都是根据系统硬件、软件来共同决定。如果从相关系统命令的输出，没看出什么峰值，或者没看出什么短板，可以针对多个不同内核版本，不同的系统类型做控制变量对比（如果有这必要）。同样的，如果能够分析出那个指标出现问题，进而判断出哪些硬件需要替换，那么就可以尝试整改。如果程序经过整改之后，得到更好的发挥，ok，那么系统瓶颈算是过了。

最后，也是最难排查的，就是程序。针对程序的性能瓶颈，其实在选型的时候就应该有第一次的筛选，是选用java，还是c，还是Python。不管选的是什么，自己心里肯定有个度，既然选了，只能扬长避短，取其精华去其糟粕了。不要花时间在优化语言短板，可以考虑用别的语言去协助开发，虽然这样看起来有点杂甚至难管理，不过有必要的话也不失一个好办法。语言的级别讨论完，就是代码级别了。同一个功能，不同的编码方式，都可能产生天与地的差别，所以我们需要不断的回顾，去优化能优化的code。而且因为程序是团队合作的结晶，很多时候，每个人都只清楚自己负责那一块，也觉得自己那部分写得很棒，这可能会导致当局者迷，所以可以考虑多人一起review，采取好的建议，将代码优化得更好。

性能优化是一个艰难的，同样也是一个很有成就感的事情，希望大家能够多点分享，一起做得更好

技术改变命运