【压⼒测试2】JMeter压⼒测试之Internalservererror500问题
解决思路
⼀、JMeter客户端实现有两种⽅式
1、Java：选择压测时，链接是复⽤的（代码中的http调⽤都加了连接池） 2、httpclient4：压测时，每请求⼀次都创建⼀个新的链接，（jmeter5.0以前默认关闭了连接复⽤，5.0上是打开的：即每请求⼀次都会创建⼀个新的链接） 从JMeter 5.0开始，当使⽤默认的HC4实现时，JMeter将在每个线程组迭代时重置HTTP状态（SSL状态+连接）。如果您不想要此⾏为，请设置set_state_on_thread_group_iteration = false
所以httpclient4 在连接复⽤设置打开的情况下，压测结果与java的是不⼀样的，因为java复⽤链接，httpclient4每次连接都会重新建⽴tcp连接，如果httpclient4吞吐量过低，需要考虑⽹络带宽的限制
java实现适合压榨性测试，httpclient4适合真实场景的模拟，
连接池的作⽤于原理：
正常访问数据库的过程中，每次访问都需要创建新的连接，这会消耗⼤量的资源；连接池的就是为数据库连接建⽴⼀个“缓冲区”，预先在缓冲池中放⼊⼀定数量的连接对象，当需要建⽴数据库连接时，只需从“缓冲池”中取出⼀个，使⽤完毕之后再放回去；且连接池允许多个客户端使⽤缓存起来的连接对象，这些对象可以连接数据库，它们是共享的、可被重复使⽤的；使⽤连接池可以节省⼤量资源，提⾼程序运⾏速度。 连接池的基本原理是：先初始化⼀定的数据库连接对象，并且把这些连接保存在连接池中。这些数据库连接的数量是由最⼩数据库连接数来设定的。连接池的最⼤数据库连接数量限定了这个连接池能占有的最⼤连接数，当应⽤程序向连接池请求的连接数超过最⼤连接数量时，这些请求将被加⼊到等待队列中。当程序需要访问数据库的时候，如果连接池中有空闲的连接，可直接得到⼀个连接；如果连接池对象中没有空闲的连接，且连接数没有达到最⼤，会创建⼀个新的连接从连接池中取出⼀个连接，数据库操作结束后，再把这个⽤完的连接重新放回连接池。
⼆、压测接⼝时，并发⼀段时间后，会报java.BindException: Address already in use: connect
原因：gff全贴合技术
Jmeter⾥的http sample勾选了keep alive，导致会话⼀直保持，⽽windows本⾝的端⼝有限，导致端⼝被占⽤完后，⽆法分配新的端⼝，因此会产⽣java.BindException: Address already in use: con
nect 报错。
现浇梁解决⽅案：
HTTP SAMPLE 不勾选keep alive
n-苯基咔唑三、Keep-Alive模式
我们知道Http协议采⽤“请求-应答”模式，当使⽤普通模式，即⾮Keep-Alive模式时，每个请求/应答，客户端和服务器都要新建⼀个连接，完成之后⽴即断开连接；当使⽤Keep-Alive模式时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建⽴或者重新建⽴连接。
http1.0中默认是关闭的，需要在http头加⼊”Connection: Keep-Alive”，才能启⽤Keep-Alive；
http 1.1中默认启⽤Keep-Alive，如果加⼊”Connection: close “才关闭。⽬前⼤部分浏览器都是⽤http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了，所以是否能完成⼀个完整的Keep- Alive连接就看服务器设置情况。 开启Keep-Alive的优缺点：
优点：Keep-Alive模式更加⾼效，因为避免了连接建⽴和释放的开销。
缺点：长时间的Tcp连接容易导致系统资源⽆效占⽤，浪费系统资源。
四、⾃动重定向与跟随重定向
Redirect Automatically（⾃动重定向）：只针对Get和Head请求，勾选此项则“跟随重定向”失效；⾃动重定向可以⾃动转向到最终⽬标页⾯，但是Jmeter是不记录重定向的过程内容，⽐如在察看结果树中是⽆法到重定向过程内容的（A重定向到B，此时只记录B的内容不去记录A的内容）
Follow Redirects（跟随重定向）：Http Request取样器的默认选项，当响应code是3xx时（301永久性转移，302暂时性转移），⾃动跳转到⽬标地址。与⾃动重定向不同，Jmeter会记录重定向过程中的所有请求响应，在查看结果树时可以看到服务器返回的内容，所以此时可以对响应的内容做关联。
五、internal server error是什么意思？
internal server error错误通常发⽣在⽤户访问⽹页的时候发⽣，该错误的意思是因特⽹服务错误。能够引起internal server error报错的原因有多个，如果你是⽹站主的话，可以对下列情形进⾏⼀⼀排查。 1、服务器资源超载
如果⽹站⽂件没有做过修改，最有可能的是同服务器的资源超载：即同⼀时间内处理器有太多的进程需要处理的时候，会出现500错误。借助SSH，可以在命令⾏中输⼊以下命令查看：ps faux ps faux |grep username 如果你查到某个进程消耗过多资源，可以⽤kill命令强制关闭这个进程，只需输⼊该进程的进程号(Pid)：kill -9 pid。
2、⽂件权限设置错误
500错误还有可能是对⽂件设置了不正确的权限：后台⽬录和⽂件的权限默认应该是755，⽽图⽚，⽂字等html⽂件应该是644，所以如果在刚刚上传⽂件后出现500错误，应该主要检查⽂件权限设置。可以使⽤FTP软件选中所有⽂件，然后批量修改⽂件权限。
3、htaccess⽂件写⼊错误的代码
在使⽤某些wordpress SEO插件的时候，插件会改写.htacess⽂件，如果语法错误的话就有可能造成500错误!
六、Internal server error 500 问题解决思路
1、明确错误含义
500 Internal Server Error
通⽤错误消息，服务器遇到了⼀个未曾预料的状况，导致了它⽆法完成对请求的处理。没有给出具体错误信息。
根据这个描述，基本可以排除客户端以及⽹络因素，需要重点关注服务端的状态。
我们系统服务端的架构如下图：
接下来就要根据这个架构由前往后⼀层⼀层排查。
活动看台2、检查HAProxy
重点排查HAProxy当前是否可⽤，负荷是否超标，包括下⾯的⼀些指标。
排查项结果
CPU是否正常正常
内存是否正常正常
线程数是否超过配置上限正常
连接数是否超过配置上限正常
排查之后发现⼀切正常，与版本更新前的数据作⽐较，也没有出现⼤幅度波动。
⽽在查看请求⽇志时，发现⼤量500错误信息，说明HAProxy出异常的可能性较⼩，错误更可能来⾃HAProxy之后的环节。
3、检查Jetty
重点排查jetty的配置信息。
排查项结果
配置是否有变动正常
应⽤占⽤的线程数是否超过上限正常
应⽤占⽤的线程数是否超过上限正常
虽然jetty配置信息检查正常，但是在access.log中存在⼤量500错误，定位到这⾥，有两种可能的原因：
应⽤代码逻辑问题。部分异常信息没有被拦截住，直接抛给Jetty，导致500错误。
Jetty逻辑问题。请求没有到达应⽤，⽽是由于Jetty⾃⾝的某些逻辑导致请求被直接返回了。
批量控制器4、检查应⽤
为了验证是否第⼀个原因，我们继续⾛查了应⽤代码，发现所有的异常都被正确处理了，不存在继续往上抛的情况。另外，也检查了图⽚保存的代码，确认⽂件连接都正确释放了。
因此，由于应⽤逻辑问题导致错误的可能性很⼩，那么第⼆个原因的嫌疑最⼤，就是Jetty逻辑问题。
如果直接排查Jetty的源码，太费时费⼒，这个时候最好的办法是实时抓包，看看Jetty和应⽤服务之间到底发⽣了什么。
5、使⽤tcpdump抓包
使⽤tcpdump命令抓取从jetty到应⽤服务之间所有的数据包，将结果输出到临时⽂件中。
tcpdump -i eth0:0 -s0 host 1X.XXX.XXX.XX -w /tmp/out1.cap
使⽤wireshark打开out1.cap⽂件，查出现500错误的数据包，然后很意外的看到了下⾯的逻辑。
通过这段代码我们发现，jetty对于请求数据的⼤⼩做了限制，超过200000 byte的时候就会报错，返回错误码500。
App这次更新后，上传了很多⼤于200000 byte的图⽚，于是便出现了⼤量的500错误。
到问题根源，修正起来就很简单了，在WEB-INF⽬录下添加l ⽂件解决，⽂件内容如下：
<?xml version="1.0"?>
tilera
<!DOCTYPE Configure PUBLIC "-//MortBay Consulting//DTD Configure//EN"
"/configure.dtd">
<Configure id="WebAppContext"class="lipse.jetty.webapp.WebAppContext">
<Set name="maxFormContentSize"type="int"> 0 </Set>
</Configure>
6、总结
出现Internal server error 500错误，往往意味着服务端出现⼀些未知异常，但是在排查的时候我们不能仅仅只是关注应⽤服务，⽽是要关注从服务端接收请求开始，⼀直到应⽤服务的整条链路。
以本⽂中的情景为例，就是从HAProxy 到 Jetty 再到 应⽤服务，中间的任何⼀个环节都有可能导致500错误。
另外，其实在⼀开始我们就可以采⽤抓包的⽅式去排查，因为在包数据中包含了完整请求/响应消息，⽐查看CPU、线程、配置信息要更加快捷，直接。
原创不易，参考：
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议