1.项目背景：新增数据接口和查询数据接口；
2.压测场景：
（1）基准场景；单用户压测接口10分钟，初步了解下该业务的响应时间和TPS；
（2）单场景负载测试；需要压测的业务使用一定数量的用户并发，压测10分钟左右，考查业务的负载情况，这个场景容易测试出来响应时间慢或者服务器资源利用率高的问题；
（3）混合场景测试；压测业务按照一定的比例混合，以客户要求的最低并发数为基准，以一定的梯度递增并发用户数压测混合业务，直至系统出现性能拐点，这个场景主要是考察系统最大的处理能力是多少；
3.稳定性测试：使用最优并发用户数的80%用户，把所有需要压测的业务按照一定的比例混合，进行压测48小时，也有压测24小时的情况。主要是考察系统长时间运行的情况，有没有内存泄漏之类的问题。
4.问题定位和思路
（1）数据库服务器CPU利用率高
数据库CPU利用率高一般是大量的逻辑读或者物理读引起的，也有可能是解析比较复杂的SQL，如果是Oracle 数据库，可以通过抓取AWR报告进行，重点看下面两项：
- SQL ordered by Gets
- SQL ordered by Physical Reads (UnOptimized)
这一部分，通过Buffer Gets对SQL语句进行排序，即通过它执行了多少个逻辑I/O来排序。顶端的注释表明一个PL/SQL单元的缓存获得(Buffer Gets)包括被这个代码块执行的所有SQL语句的Buffer Gets。大量的逻辑读往往伴随着较高的CPU消耗，在这里的Buffer Gets是一个累积值，所以这个值大并不一定意味着这条语句的性能存在问题。通常我们可以通过对比该条语句的Buffer Gets和physical reads值，如果这两个比较接近，肯定这条语句是存在问题的 ，如果对比差别不大，可以关注 **gets per exec的值，这个值如果太大，表明这条语句可能使用了一个比较差的索引或者使用了不当的表连接。
另外还可以通过查看使用CPU高的进程ID，根据进程ID查找对应的SQL ID，从而找出相应的sql语句。
（2）应用服务器CPU利用率高
使用top命令查看占用CPU最高的进程
查看进程下所有线程信息，可以使用top，也可以使用ps命令
top -p pid -H
-p 表示进程PID
-c 显示进程的绝对路径
-H 显示进程的所有线程
也可以用下面的命令将 cpu 占用率高的线程找出来:
ps H -eo user,pid,ppid,tid,time,%cpu,cmd --sort=%cpu
找到了占用cpu最高的两个线程，要查看线程的信息, 把上面的进程信息dump下来，然后在文件查找线程信息，不是直接dump线程信息。线程对应的是栈，在栈中可以看到线程操作了哪些数据
（2）响应时间慢
响应时间慢可以从两个方面来分析，一是查看AWR报告，或者在数据库中搜索慢的sql，在AWR报告中需要关注下面两项：
SQL ordered by Elapsed Time
SQL ordered by CPU Time
一般sql的慢是没加索引或者索引失效引起的，也有可能是查询方式过于复杂，表的关联关系不对，小表驱动大表，或者在sql语句中进行了大量的计算，具体的问题需要DBA或者开发人员进行分析。
如果不是慢sql引起的，则需要查找程序的问题，可以通过压测工具定位到具体方法，也可以dump进程，查看是否有锁争用、死锁或者资源等待的情况。在本次压测中出现了大量dubbo服务等待数据库响应的线程，数据库的CPU利用率达到90%，导致应用的大部分进程是sleeping状态，通过查看dump下来的线程发现大部分处于Runable状态，而他们都在等待锁住同一资源（数据库）。增加数据库CPU之后，响应时间慢的问题得到解决。
（3）稳定性压测内存泄漏
稳定压测的前20小时之内，系统很稳定，20小时之后，出现了大量的报错，并且报错信息一直增加，部分交易响应时间达到二十几秒，数据库服务器几乎没有压力，查看weblogic进程，几乎没有工作（占用的cpu资源0.5%左右），但有一个java进程CPU使用率很高：
可以使用Jmap，观察运行中的jvm物理内存的占用情况；