index方法压力测试记录
相关参数
JMeter参数的设置
线程数：1000
Ramp-up Period ：0
循环次数：2
也就是说立即启动1000个线程去执行2000个请求
index接口参数的设置
都是请求首页接口，所有 参数都一样，除了uid，uid进行参数化。
总共提供了4100个不同的uid
总的来说就是用1000个线程来模拟2000个不同的用户尽快的请求首页接口
代码修改（仅仅添加了耗时的统计）
测试
通过nginx转发的测试
- 准备工作
/data/jetty-web/bin/jetty.sh restart echo "" > /data/jetty-web/logs/2016_10_29.stderrout.log tail -f /data/jetty-web/logs/2016_10_29.stderrout.log > /data/have_nginx_jetty.txt echo "" > /data/nginx/access.log tail -f /data/nginx/access.log > /data/have_nginx_access.txt - 启动JMeter
- 结果
jetty日志没有异常，显示我们的程序共成功处理了1998个请求，成功吧数据发送给客户端的请求有1998个请求。也就是说可以说jetty几乎成功处理了全部请求。
那为什么客户端却只显示只有1390个请求处理成功了呢？
再来看看nginx的访问日志
那么为什么nginx会和客户端交互这么长时间? 其实也不是nginx的问题。jetty成功请求到发送数据，看截图可以看到两个最长时间加起来也不到4.1秒，算它5秒了，减去这5s,nginx与客户端的交互时间最长的到了了47秒。
问题在于客户端，下面的测试进一步验证
绕过nginx转发的测试
- 准备工作
/data/jetty-web/bin/jetty.sh restart echo "" > /data/jetty-web/logs/2016_10_29.stderrout.log tail -f /data/jetty-web/logs/2016_10_29.stderrout.log > /data/no_nginx_jetty.txt - 启动JMeter
- 结果
从jetty日志中可以看到，我们的程序总共成功处理了1005个请求，成功把数据发送给客户端的请求有810个。
那么客户端显示的成功请求个数应该是小于等于这个数据了，可以看到客户端显示的成功请求个数是762。
那为什么要少于810，只能说不确定因素比如网络，反正不是810-762的这些请求没有成功，肯定不是服务端的问题了。
我们的程序共成功处理了1005个请求，jmeter显示只有762个请求成功，那么1005-762个，大约240个请求发生什么事了呢？：就是数据没有成功发送给客户端，没有成功的原因就是客户端没能及时读取数据，导致超时，然后超时导致了刚才看到的jetty异常信息。
jetty共处理了1005个请求，那其他的955个请求根本没有处理，这是什么原因造成的？
这个原因不能确定，也许是之前的异常引发的连锁反应，也有可能是其他什么原因，反正可以确定，那就是不是我们程序的问题了。
jetty异常的解释：
结论
对广场首页的压测结果不理想的原因基本可以可以排除服务端的问题。当然也并不能证明服务端程序能够承受住很大的并发。
- 随机毒鸡汤：那些你认为不靠谱的人生里，充满你没勇气做的事。
