性能优化： 明确项目性能目标

      从一个公司接到需要开发的项目那一刻开始，性能问题就已经隐藏于项目当中，从项目的需求分析到功能设计，业务架构设计，功能开发，乃至于项目成功上线，都会有性能问题的影子，只是或多或少罢了。用户常常抱怨这系统真烂、页面一直在转圈、怎么回事、系统又503了等等问题，都来源于性能问题。

      性能问题常常影响用户体验，在网上看到有贴图公司在服务器上线前，请道士作法保佑服务器千万别出问题，虽然这种作法比较搞笑，但从另一个角度反应了对开发出的软件质量有多么不放心。功能问题还可以忍耐，但是如果刚上线，服务器挂了导致无法使用给公司带来的损失是比较大的，轻则赔礼道歉，重则以后再也接不到某重要的客户的项目，同时也说明了软件没有经过性能方面的测试。因此，在项目的初期，需要制订出项目的性能目标。

      性能目标即开发的项目在完成上线后是否能满足用户的需求，或者对外提供的用户群体在项目发布之后，系统能否支撑这种群体在被瞬时使用或长时使用而不会宕机。因此需要在项目初期进行合理的评估，然后在项目的设计、开发、测试中充分考虑是否能满足这种需求，不能满足便会出现性能问题。这种需求即是项目的性能目标，需要按实际的情况来明确。如果明确的性能目标供大于求，则会出现浪费资源；性能目标供小于求，就会出现宕机、假死等现象；如能做到恰如其分，即能省钱也能省人力，又能拿到客户或用户的好评，所谓一举三得。

      那么影响性能的指标有哪些呢？它包括如下指标：

1. 执行时间：程序的一段代码从开始到运行到运行结束，所使用的时间。
2. CPU时间：函数或者线程占用CPU的处理时间。【通常密集计算型线程数越多，CPU的核数将会被争抢，导致性能下降】
3. 内存分配：程序在运行时占用的内存空间。【根据业务处理量与用户同一时间的访问量来决定，需要压测模似目标要求】
4. 磁盘吞吐量【I/O】：磁盘数据每秒读写的速度。磁盘I/O读写速度比内存慢很多，程序在运行中如果要进行大量的磁盘读写操作，那么提高磁盘I/O的速度就尤为重要，否则会拖累整个系统 。比如大量es，kafka读写数据时会进行磁盘读写操作，因此需要提高磁盘介质，如用更快的SSD硬盘。
5. 网络吞吐量【I/O】：网络数据每秒读写的速度。由于网络环境不确定性，网络操作的速度可能比本地磁盘I/O更慢。因此会成为影响性能的重要因素之一。
6. 响应时间：系统对用户做的某一操作所做出的响应时间，响应时间越短，性能越好，用户体验也越好。此响应时间包括了执行时间、CPU时间、磁盘读写时间以及网络传输时间。

      项目依赖的载体是硬件资源服务器，服务器也是重要考虑的因素之一，服务器资源使性能指标有了量化，我们不能光一昧制订我们的指标有多高，结果硬件资源却有限，那就会出现巧夫难为无米之炊的尴尬境地。硬件资源一般包括如下：

1. 服务器CPU核数：核数决定处理计算型任务的速度，为并发提供保障的因素之一。
2. 服务器硬盘类型：固态还是机械硬盘。固态也有速率高低之分。有没有用固态必要？
3. 服务器内存容量：内存与处理的业务有关，也与设计有关，好的设计能降低内存使用。
4. 服务器网络带宽与速率：它是影响响应时间的重要因素之一，如果服务器处理非常快，拥挤的网络如龟速，用户体验会很差。因此会用CDN以避免网络拥堵。

      当项目负责人员评估并制订好项目的性能目标后，进行业务架构设计时要充分考虑制订的性能目标，优化设计，这样在后期才不会因设计差，想改设计时发现已经无法轻易改变。开发过程中要对代码进行做相应的性能检测分析优化，以避免后期发现性能问题而有大改动，却又因人员变动不敢乱改，后期压力测试是最后一道关卡，压力测试的好与坏直接决定了项目的性能问题能在上线前暴露多少。上线前保证了性能指标能达到预订的标准，则项目的成功将会达到95%以上，剩余的3%是功能Bug，1%是机房故障【可忽略，如果有就不是你一家服务器出问题了】。1%是网络拥挤【没有做好CDN，上线前肯定需要做好提前模似测试的】。一般情况下做完了上面的保证之后，运行可靠性就不会有问题。

      因此，别小看了项目之初的明确性能目标，它将会影响整个项目的成败。如果真有人要说不影响的话，就是那种上线半年不用的项目，只求验收时用一下而已，只要保证一个人点点功能可以出来结果，那样只是个玩具而已，真开始用时，才发现钱打水漂了，这种情况不包含在些性能优化分析内。