思路：


那么是什么原因会导致“表象”是软件的压力顶点呢？
本身就是软件处理能力极限，原因很多啊（这里不考虑系统资源与带宽）
（1）是不是架构的原因？比如某些架构里面有些外围系统性能导致你本身测试的系统反应不过来。（可以挡板一把再测试）
（2）是不是代码原因？比如某些业务逻辑处理复杂，或者是异常处理抛错，但研发人员将此抛错捕获，然后做一些异常finally的动作导致处理很慢，甚至调用一些系统内核的函数导致反复翻页（这个要研发人员优化代码哦）
（3）是不是中间件配置原因？比如某些中间件的线程数不够，你要监控线程数是不是达到你配置的最大值，同时等待时间，超时时间等要统一考虑。又或者是不是数据库连接池的配置不对，其实基准测试的时候就该搞清楚嘛。
（4）是不是数据库原因？。例如：数据库某些存储过程响应时间就很慢，或者说是相关表的索引字段建的对不对，是不是有全表扫描，请求锁情况怎么样。缓存点击率呢？某些表的数据超大，有木有分表机制哦。。。等等
（5）是不是其他原因，例如java虚拟机的内存达到顶峰，，又或者本身就是你压力机的CPU满了，哥你尴尬啦


（6） 代码因素还有一个例子，就是说代码中一些成熟的线程管理lib，也不一定都OK，多线程安全机制要根据实际情况来哦。 
这里排除资源利用率（CPU，内存，磁盘IO等）与网络因素