1. 首先明确下并发的概念。在性能测试中并发可以理解为同一时刻做不同的事，或同一时刻做同样的事。一般我们在性能测试的时候也是这么去模拟的。那这个同一时刻的并发是很难做到的。

　　要知道我们用来发起压力的测试工具本身要能做到同一时刻发起压力，如果设置线程数过多，负载机本身资源不足会有排队，请求建立和服务端的连接过程会排队，请求数据发送到服务的时候在网络队列上也会排队，请求数据达到服务端，在服务端也会进行排队，所以严格意义上的并发多少用户数等等是比较难做到的。

　　但是，并发我们可以分层去看，像一般的webserver或容器服务都有监控数据，如nginx的Active connections，tomcat的currentThreadsBusy，这些参数表明服务本身目前正在处理的最大并发线程数。到了代码层每个方法的实际并发数又是另一回事。根据请求的到达情况来看，每一层的并发数都会有不同。使用一台机器发起600个线程，和使用2台机器各发起300线程，从服务端的请求达到情况来看，确实会存在不一样的情况。

　　2. 性能测试中不只关注并发数。尤其是单接口性能测试的时候，更多关注吞吐量、响应时间等指标来评估服务端性能。验证服务端最高每秒能正确处理的请求数，以及请求的响应延时情况。曾经看过并实施过RBI性能测试方法，快速瓶颈识别法。

　　RBI强调了80%的性能问题可以通过吞吐量测试来发现，其他20%的性能问题可以通过引入并发用户数等更复杂的场景来发现。推荐有空可以看看。

　　3. 对压测中出现的异常或错误，可以尝试自己分析下。Response code: 500通常情况下是服务端出现问题，可以查看服务端的日志，看看是否有异常或错误信息，根据提示信息来定位分析，排查的时候可以根据服务端的业务架构一层层的排查下去，直至找到发生问题的服务。对自己没见过的或不太熟悉的错误信息建议google。 比如：Non HTTP response code: java.net.SocketException这种错误，google一把大致就有些可行的解决方案。

作者：Linsa    

来源：http://www.51testing.com/html/09/n-4478109.html