共计 1137 个字符，预计需要花费 3 分钟才能阅读完成。
在并发量一定的情况下如何对系统响应时间进行详细分析
分析步骤 1.1 在关键点位添加日志信息 -> 缩小目标范围
a) 主要函数耗时
b) 访问外部系统耗时：DB、MQ、Cache、FileSystem、RPC、HTTP 等
c) 接口内不同逻辑耗时百分比 / 绝对值
1.2 详细分析瓶颈出现原因
a) 技术层面：优先考虑
b) 业务逻辑：业务逻辑改造一般影响较大、耗时较长，优先级低
1.3 针对性解决问题
一旦定位了问题原因，解决问题的方法都相当容易
技术层面 2.1 代码实现
a) 串行逻辑是否可以并行化
b) 串行请求是否可以批量 (batch) 请求
c) SQL 是否需要优化
d) 算法复杂度是否需要优化
e) 语言核心库是否提供了性能更高的使用方式
f) 引用的第三方库是否存在性能问题
g) 每次外部请求是否都重新建立连接
2.2 内核 / 硬件层面
a) CPU 使用率
b) 内存使用率
c) 磁盘 IO 状况
d) 网络状况
d) 瓶颈是否由调用的内核函数引起？
该函数是如何工作的；新版本内核是否已经对此优化；如何调整使用方式可以更高效
2.3 日志
线程会争夺日志锁，在高并发情况下，同步写日志很影响性能。异步写又可能引起 OOM。
业务逻辑随着业务的增长，接口负担的功能原来越复杂，逻辑链路越来越长，事务越来越大，性能越来越差，越来越没办法维护。（如果有人负责把控、从相对长远些的角度设计系统的迭代，这种情况本是可以避免的）
优化办法只有一个就是：保留主链路，旁支链路异步化。
常用工具 4.1 内核
a) CPU: top、vmstat htop w uptime dstat
b) MEM: top、free
c) disk IO: iostat
例: iostat -kx 1 // 每秒统计一次 io
iotop -o // 查看磁盘使用率较高的进程
d) 网络
流量：sar -n DEV 1 3 // 每秒统计一次所有网卡流量，共 3 次
网络抓包: tmpdump，可配合 tmptrace、wireshark 分析
TCP 连接状况：netstat -an | grep TIME_WAIT //client 端近期关闭 tcp 连接数量
e) 查看 /proc/xxx 中的系统详细信息
小知识 a) 网络抖动引起 tcp 重传，一般内部系统之间的调用，linux 设置的重传时间间隔为至少 200ms 以上。
b) 服务之间通过网络调用，网络开销在 500us ~ 2ms
c) 机械磁盘寻址: 20ms
d) 磁盘的某 page 中如果存在数据，程序写此 page 时如果不会填充整个 page，内核会先载入整个 page，再输出整个 page，保证磁盘数据不丢。这会导致一次被动读磁盘，性能损耗会很大。否则会直接写入磁盘高速缓存，间隔固定时间刷盘一次(5s)。
e) 日志使用 seaslog buffer
随着系统并发量的增加，系统响应时间会逐步下降甚至雪崩，一般是由多线程之间、模块之间、子系统之间争夺资源（锁）引起的。
