1. 单线程业务处理能力70caps
基本业务没有明显的高复杂度的算法，内存，网络均没有问题。因此初步排查是否数据库每条commit导致，结果却是如此。原因是因为disk的iops大概在70左右。
2.业务处理200caps
经过初步检视，有同事guard锁里面有情况sleep了。修改后解决。
3.业务处理250caps
由于编写代码的工程师没有在关闭连接时打印日志，因此，我是在lsof -i:port 时，发现有句柄不停变化。
因为与SSDB连接都是长连接，因此，肯定有断连，重连。因此排查，发现确实在close。
最后发现 SSDB Status比较坑。 error() { return _rec != "ok"; }。因此修改写法不能使用error()来判断断连后解决。
4.业务处理250caps
经过分析代码，加调测日志。（痛苦的过程，原因是gprof莫名不能打印出部分信息非setittimer问题)
发现每次业务需要进行3次耗时1ms/次的串行流程，该兄弟开启的单线程处理。因此只能达到250caps每秒。
5.两台服务器集群情况下，一台队列堵，一台不堵
300caps时，经过日志分析。发现3次耗时1ms/次的串行任务在同一台服务器上执行，因此这台会堵。另外一台不堵。
修改为两台均衡处理。
6.不能使用gprof的原因
程序启停时，使用的kill -9。线程没有正常关闭，因此该部分内容无信息。经过修改为退出前停线程后，可以使用gprof来定位问题。
经过gprof检测，发现没有代码占用较多时间。因此，不是程序复杂计算导致性能不高。
7.ACE_Message_Queue堵
通过netstat -an|grep xxx观察发现，该模块接收队列过大（6000多），实际应该如下图所示。
因此，通过接收部分排查代码，发现是ACE_Message_Queue的高低水位没有设置。
8.持久化超时组件性能瓶颈
持久化超时组件在add和del事件时，需要加锁串行化处理。因此依赖与SSDB交互的网络状况。
业务逻辑单元将整个业务的各个超时任务均注册在同一个超时组件上。因此每次业务需要add,del各7次。
由于网络当时只能支持1000的读写。因此实际150*7=1050 > 1000会造成堵塞。
解决方法是，分离各个超时任务，并行处理。
9.模块订购，退订，升降级大量超时
单线程处理，业务流程中多次数据库commit，数据库AWR报表显示 commit 占用80%DB time。
减少commit次数，降低性能指标。无须开启线程池，开启2个线程即可，因为业务模型中必然有commit。