“系统慢”，这是任何一个应用都会出现的问题，面对“系统慢”的问题，客户、测试、开发、管理者等不同角色的人员有不同反应：
客户：啥破东西啊，这么卡！
测试：性能bug已提交。
开发：我本地很快啊，要不你重启一下！
管理者：开会了。
OK！“屁股决定脑袋”，扯淡结束，回归正题。
为了便于区分，根据web请求响应模型，粗略分成客户端慢、服务端慢。
客户端慢
客户端慢的原因比较难以控制（客户端的环境影响），因为差异性太大，且大部分原因是客户端所在环境导致，每个终端的情况可能都不一样；因此这里只做归纳，不做具体指导。
但是在我们设计功能时需要考虑客户端慢的情况，比如物联网设备的弱网环境、客户端带宽不足导致视频通话或者影视观看卡顿、大型集会现场通过手机流量上网造成的基站通道拥堵（几万人的活动现场、无运营商加持，只通过当地基站，特别是拍照发朋友圈）。
如果是因为应用导致的客户端慢，这个还是要重视，一般这种情况都归结于服务端慢，比如现场签到（扫同一个码）抽红包，扫码没有反应，客户端一直在转圈直到超时，排除客户端网络环境良好的原因，那么就是我们扫码服务接口对并发支持不够导致（这种都会在后面服务端慢找对应的）
服务端慢
一般web应用慢，默认指服务端慢。因此本文重点讲解服务端慢。
服务端慢的情况有很多：如下图所示，图一中每一个环节都可能会导致“系统慢”，再详细点如图二所示，一个web页面请求和响应整个过程中的每个节点都会导致“系统慢”，包括：服务器、网络、客户端浏览器、服务端的组件和应用。
比如：web应用中的文件上传入库功能，多客户并发的上传大xls文件，100个用户并行上传100M的xls文件，并行上传过程中，服务端不仅仅要接受文件、还要打开文件逐行解析入库，不仅仅占用服务器带宽、CPU/内存/磁盘/数据库/JVM/GC都有影响。
服务端慢的原因
- 网络攻击：DDos攻击、网站CC攻击、XSS跨网脚本攻击、CSRF等； 如ddos这种，占用服务端连接数，让正常业务请求无路可走。
- 服务器带宽不足：服务器带宽不足会导致网络拥堵，web应用访问变慢，以及访问报错（408 request timeout，504 gateway timeout），影响客户体验，最终会导致潜在客户流失。
- 服务器资源不足：（cpu/内存/磁盘/网卡/显卡等性能瓶颈）、容器性能瓶颈（docker等），
- 中间件慢：（RPC框架、WEB服务器、MQ消息队列（KFK、RocketMQ、RabbitMQ等）、
- 数据库慢：（关系型数据库Oracle、MySQL、PostgreSQL、SQL Server等；非关系型数据库Redis、MongoDB，ElasticSearch等）、
- 应用慢：（前端页面加载慢、jvm、GC、锁、线程池、java容器使用不当、业务设计不合理、框架设计不合理、写日志文件、并发）
当然很多服务端慢的情况都是关联影响的，需要综合具体情况具体分析。这里先做一个概叙，待后续整理发布。
一、性能优化考虑点
当我需要进行性能优化时，说明我们服务器无法满足日益增长的业务。性能优化是一个比较大的课题，需要从以下2个方面进行探讨。
- 当前系统结构瓶颈
- 了解业务模式 原理、性能和安全
二、当前系统结构瓶颈
首先需要了解的是当前系统瓶颈，用的是什么，跑的什么业务。里面的服务是什么样子，每个服务最大支持多少并发。比如针对Nginx而言，我们处理静态资源最高的并发是多大。
- 可以通过查看当前cpu负荷，内存使用率，进程使用率来做简单判断。还可以通过操作系统的一些工具来判断当前系统性能瓶颈，如分析对应日志，查看请求数量。
- 也可以通过nginx vts模块来查看对应的连接数，总握手次数，总请求数。以对上线进行压力测试，来了解当前的系统的性能，并发数，做好性能评估。
三、了解业务模式
虽然我们是在做性能优化，但还是要熟悉业务，最终目的都是为了业务服务的。我们要了解每一个接口业务类型是什么样的业务，
比如电商抢购模式，这种情况配是流量会很小，但是到了抢购时间，流量一下子就会猛涨。也要了解系统层级结构，每一层中间层做的是代理还是动静分离，还是后台进行直接服务。需要我们对业务接入层和系统层次要有一个梳理。
图一 web软件架构图
图二 基于springclod的软件架构图
