硬件

如果是硬件瓶颈就换硬件 （包括CPU、内存、网卡、硬盘）

软件

（软件，特指我们写代码的那部分程序）

建议先 top 看下软件瓶颈在哪，CPU、内存、网络（netstat），哪个进程占用比较高

还有硬盘I/O等，一般情况比较少

（有时候可能不是自己代码的问题，也可能是第三方库的问题，需要注意）

CPU

是bug

比如，CPU异常 100%，C程序需要拿 gdb、pstack 工具去调试看看是不是死循环了

不是bug

看看需不需要分散CPU压力，多线程或者是集群分布式分担压力，参考方案优化

内存

是bug

比如内存泄漏，C代码用 valgrind 排查泄漏点

不是bug

比如有些数组申请过长（比如1000），看下是不是能改个800，做一些代码层的优化（这种不属于内存泄漏），可能还需要配合打印日志，比如某个阶段占用的内存

还有就是参考方案优化

网络

可以先 netstat 看下发送或者接收队列有没有堆积，此外还可以结合抓包定位问题

内部问题

如果是服务器侧问题（是不是我们代码处理并发不太合理），考虑I/O多路复用等

外部问题

和我们对接的客户端流量过高，要不要限制客户端流量，方案是否能做优化（或者分布式分散压力）

中间件

还有一些性能问题可能不是在我们写的程序里面，可能在mysql、redis等中间件里，一般是两种情况，中间件一般都带有自己的调试日志，比如mysql就可以打印慢查询的sql语句，我们可以结合日志和我们代码一起分析

中间件返回时间过长

这个需要结合代码和中间件日志分析，这个比较影响 tps

比如mysql是不是发送慢查询、redis是不是有大key存在

中间件CPU、内存占用过高

这个需要结合代码和中间件日志分析，这个比较影响服务器整体性能

看下是不是我们代码导致的上诉问题，如果不是的话，就是业务量实在太大，可以考虑优化方案

方案设计

如果软件硬件都优化到瓶颈了，看看是不是方案问题，比如说考虑架构上考虑分布式，通过分布式思想来分散CPU、内存、网络压力，把单一压力打散到各个点上；比如程序上是否可以考虑多进程，多线程方式，反正就是分散压力；中间件也考虑分布式来分散压力