“系统慢”，这是任何一个应用都会出现的问题，面对“系统慢”的问题，客户、测试、开发、管理者等不同角色的人员有不同反应：
客户：啥破东西啊，这么卡！
测试：性能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容器使用不当、业务设计不合理、框架设计不合理、写日志文件、并发）
当然很多服务端慢的情况都是关联影响的，需要综合具体情况具体分析。这里先做一个概叙，待后续整理发布。
图一 web软件架构图
图二 基于springclod的软件架构图
