江苏龙网

  1. 主页 > 生活百科 > >

Nginx和Tomcat配合实现Java Web服务热部署( 二 )

服务热部署

和上面没有经过Nginx的压测相比，最明显的变化就是QPS下降了84%，平均响应时间增加了5倍，猜测可能是因为Nginx使用的默认配置中worker_processes 1;的问题 。

  1. 在开始压测后立即删除tomcat-active容器中的war包和目录，结果如下
$ wrk -c 20 -d 10 -t 4 http://192.168.99.100:32778/helloRunning 10s test @ http://192.168.99.100:32778/hello4 threads and 20 connectionsThread StatsAvgStdevMax+/- StdevLatency57.29ms28.69ms 181.88ms67.38%Req/Sec87.9339.51240.0075.25%3521 requests in 10.05s, 553.50KB readRequests/sec:350.22Transfer/sec:55.05KB同样没有非200的响应，而且整体和正常情况相当 。
  1. 只有standby节点工作的情况下压测
$ wrk -c 20 -d 10 -t 4 http://192.168.99.100:32778/helloRunning 10s test @ http://192.168.99.100:32778/hello4 threads and 20 connectionsThread StatsAvgStdevMax+/- StdevLatency72.12ms35.99ms 240.89ms68.34%Req/Sec70.0431.84180.0076.50%2810 requests in 10.05s, 441.71KB readRequests/sec:279.48Transfer/sec:43.93KB可以看到，响应时间有明显的增加，QPS也有明显的下降，也验证了上面说的响应是404的请求会被转发到正常工作的节点，但有问题的节点不会被摘除导致的响应时间变长的问题 。
进一步测试为了消除上面测试中可能存在war包删除后对服务的影响还没有生效，压测就已经结束的可能，将压测时间调长，增加至60s 。
  1. 两个节点都正常的情况
$ wrk -c 20 -d 60 -t 4 http://192.168.99.100:32778/helloRunning 1m test @ http://192.168.99.100:32778/hello4 threads and 20 connectionsThread StatsAvgStdevMax+/- StdevLatency55.53ms28.10ms 306.58ms70.07%Req/Sec91.5239.35300.0069.23%21906 requests in 1.00m, 3.36MB readRequests/sec:364.66Transfer/sec:57.32KB整体情况和上面10s的测试相同 。查看日志发现backup节点没有接收到任何请求 。为了验证是否是worker_processes配置导致的，把这个值改成4之后重新测试，结果如下
$ wrk -c 20 -d 60 -t 4 http://192.168.99.100:32778/helloRunning 1m test @ http://192.168.99.100:32778/hello4 threads and 20 connectionsThread StatsAvgStdevMax+/- StdevLatency41.55ms24.92ms 227.15ms72.21%Req/Sec125.0646.88373.0071.76%29922 requests in 1.00m, 4.59MB readRequests/sec:498.11Transfer/sec:78.29KB可以看到，有了将近20%的提升，但还是不太符合预期 。
  1. 开始测试后立即更新active节点的war包
$ wrk -c 20 -d 60 -t 4 http://192.168.99.100:32778/helloRunning 1m test @ http://192.168.99.100:32778/hello4 threads and 20 connectionsThread StatsAvgStdevMax+/- StdevLatency54.40ms33.76ms 329.73ms70.53%Req/Sec95.8556.28420.0081.60%22914 requests in 1.00m, 3.52MB readRequests/sec:381.42Transfer/sec:59.95KB没有明显变化，测试开始后有一段时间standby节点收到请求，后面请求又全部指向了active节点 。可能是因为服务太简单，重新加载的太快，只有很少量（5750）的请求转发到了standby节点，所以对整体结果影响不大 。3. 开始测试后立即删除active节点的war包
$ wrk -c 20 -d 60 -t 4 http://192.168.99.100:32778/helloRunning 1m test @ http://192.168.99.100:32778/hello4 threads and 20 connectionsThread StatsAvgStdevMax+/- StdevLatency72.11ms34.33ms 346.24ms69.54%Req/Sec70.1629.78191.0067.23%16813 requests in 1.00m, 2.58MB readRequests/sec:279.84Transfer/sec:43.99KB删除节点后，所有的请求都会先请求active，然后被Nginx转发至standby，所以吞吐量有明显下降，延迟也有明显的提升 。
效果测试
  1. 直接访问active
$ wrk -c 20 -d 60 -t 4 http://10.75.1.42:28080/web-0.0.1-SNAPSHOT/helloRunning 1m test @ http://10.75.1.42:28080/web-0.0.1-SNAPSHOT/hello4 threads and 20 connectionsThread StatsAvgStdevMax+/- StdevLatency5.56ms25.16ms 203.83ms95.82%Req/Sec7.54k0.91k8.31k84.44%1803421 requests in 1.00m, 217.03MB readRequests/sec:30006.18Transfer/sec:3.61MB服务器的性能果然还是比本地强太多 。
  1. 在进行性能压测期间发布新版本
$ wrk -c 20 -d 60 -t 4 http://10.75.1.42:28080/web-0.0.1-SNAPSHOT/helloRunning 1m test @ http://10.75.1.42:28080/web-0.0.1-SNAPSHOT/hello4 threads and 20 connectionsThread StatsAvgStdevMax+/- StdevLatency4.47ms22.31ms 401.95ms96.67%Req/Sec7.58k0.88k8.26k87.12%1811240 requests in 1.00m, 285.84MB readNon-2xx or 3xx responses: 72742Requests/sec:30181.93Transfer/sec:4.76MB发布新版本导致4%的请求失败 。
  1. 通过Nginx访问服务
$ wrk -c 20 -d 60 -t 4 http://10.75.1.42:28010/web/helloRunning 1m test @ http://10.75.1.42:28010/web/hello4 threads and 20 connectionsThread StatsAvgStdevMax+/- StdevLatency2.94ms16.21ms 248.18ms98.01%Req/Sec6.02k551.526.92k83.38%1437098 requests in 1.00m, 260.33MB readRequests/sec:23948.20Transfer/sec:4.34MB


推荐阅读


上一篇：60亿次for循环，原来这么多东西

下一篇：使用Docker来构建、运行、发布微服务