在一定并发量的情况下如何详细分析系统响应时间分析步骤1.1在关键点添加日志信息->缩小目标范围a)主函数耗时b)耗时访问外部系统：DB、MQ、Cache、FileSystem、RPC、HTTP等c)接口不同逻辑的耗时百分比/绝对值1.2瓶颈原因详解时间长，优先级低1.3有针对性问题解决一旦定位到问题的原因，解决问题就很容易了技术层面2.1代码实现a)串行逻辑是否可以并行b)串行请求是否可以批量请求c)SQL是否需要d)算法复杂度是否需要优化e)语言核心库是否提供了更高性能的使用方法f)引用的第三方库是否存在性能问题g)每次外部请求是否重新建立连接2.2Kernel/hardwarelevela)CPU占用率b)内存占用率c)磁盘IO状态d)网络状态d)是否是被调用的内核函数导致的瓶颈？这个功能是如何工作的；新版本内核是否对其进行了优化；如何调整使用方式更高效2.3日志线程会竞争日志锁。在高并发的情况下，同步写入日志会极大地影响性能。异步写可能会导致OOM。业务逻辑随着业务的增长，接口所背负的功能越来越复杂，逻辑链路越来越长，事务越来越大，性能越来越差，越来越难维护。（如果有人从比较长远的角度负责控制和设计系统的迭代，这种情况是可以避免的。）优化方法只有一个：保留主链路，异步化副链路。常用工具4.1kernela)CPU:top,vmstathtopwuptimedstatb)MEM:top,freec)diskIO:iostat例子：iostat-kx1//每秒统计一次ioiotop-o//查看磁盘占用率高的进程d)网络流量：sar-nDEV13//每秒统计一次所有网卡流量，共3次网络抓包：tmpdump，可以配合tmptrace，wireshark分析TCP连接状态：netstat-an|grepTIME_WAIT//client终端最近关闭的tcp连接数e)查看/proc/xxx中的系统详细信息。Tipsa)网络抖动导致tcp重传。一般linux设置的重传间隔对于内部系统之间的调用至少要200ms。b)服务之间的网络调用，网络开销为500us~2msc)机械磁盘寻址：20msd)如果磁盘的某个page中有数据，如果程序在写这个page的时候没有填满整个page，kernel会先加载整个页面，再输出整个页面，保证磁盘数据不丢失。这样会造成被动的磁盘读取，性能损失会很大。否则直接写入磁盘缓存，磁盘会定时（5s）刷新。e)日志使用seaslogbuffer。随着系统并发量的增加，系统响应时间会逐渐减少甚至雪崩，这通常是由于多个线程、模块、子系统之间对资源（锁）的竞争造成的。
