码迷,mamicode.com
首页 > 其他好文 > 详细

(转)一次压测对nginx/tomcat配置的调整

时间:2018-05-18 18:04:00      阅读:160      评论:0      收藏:0      [点我收藏+]

标签:第一个   反向代理   gre   mysq   一点   文档   默认   nginx   netstat命令   

原文地址:还在寻找....

  一个web系统,前端使用nginx做为反向代理,处理https,并将请求转发给后端的tomcat服务。

  压力测试工具选择了jmeter。 首先简单介绍一下jmeter。 它是apache的一个开源项目,基于java swing开发的GUI界面。 jmeter提供了许多高级的功能,但我们仅仅使用了jmeter最简单的功能。在简单的jmeter使用中,我们涉及到这么几个概念:测试计划,线程组,测试任务,和Listener。看下面的图: 

技术分享图片

 

在一个名为“测试”的测试计划下, 我们建立了一个线程组。 这个线程组可以设置线程数,创建时间(在多长时间内创建出这么多个线程),每个线程任务循环执行次数。 然后为这个线程组指派了一个http请求任务。 这个任务可以指定协议(http或https),服务器, url,参数等。

接下来为这个http请求任务添加了一个aggregate graph类型的listener。 我们需要看最终的测试结果, 这个listener就是为我们记录并展示结果的。

一切设置就绪之后,点击主界面上边的“启动”按钮,就可以在aggregate graph中观看测试结果了。 
我们所测试的后端tomcat,执行了一次mysql数据库的查询请求,并执行了一次通过http协议请求内网其它服务器的远程请求。

尝试着调整并发压力测试的线程数,发现QPS留在600/sec,始终无法提升, 而此时cpu的消耗只有40%左右,显然cpu还未到瓶颈。 而https处理和这样的web server,根据经验瓶颈一般出现在cpu上,为什么cpu还未到达瓶颈,qps就上不去了呢。

接下来我们在nginx的access log中增加了 $request_time这一项, 在tomcat服务中也打了日志观测执行时间。 发现nginx的时间远大于tomcat的处理时间。 原来瓶颈点在nginx这里。 
尝试优化一下nginx的参数,第一个看到的是,由于这是一台测试机,nginx采用的大部分配置都是默认设置,worker_processes参数被设置为1. 把这个数字调整为4的时候, QPS提升到了 1200, cpu利用率达到了99%. 看来这个就是这台测试机硬件配置的极限了。

那么单个worker_processes的时候,为什么cpu利用率上不去,java进程尚未充分利用硬件资源,而nginx先到达瓶颈呢? 对比测试一下, 当访问硬盘上一个静态html页面的时候, 单个worker进程qps可以达到9000+。静态资源和proxy_pass的差别在于读取本地磁盘文件(可能有内存缓存),和向后端建立socket连接。团队里的技术大牛通过strace跟踪了一下,也未找出明显的问题根源,推测是在向后端建立连接的地方会出现排队等待现象。

在我们压测的过程中, 通过netstat命令可以看到有很多nginx向tomcat发起的连接。 这些连接都是短连接,每次用完即关闭。于是想到nginx向后端源服务器能否建立长连接的问题。查看了一下文档,nginx从1.1.4版本开始,支持proxy_pass的时候向后端源服务器建立长连接。

根据官网的描述,若采用长连接,必须在proxy_pass的时候使用upstream的方式, 直接把后端源写在proxy_pass后边是不行的。 具体的配置方式如下: 
定义upstream: 
upstream lich { 
server 127.0.0.1:8081; 
keepalive 128; 
}

proxy_pass的地方: 
proxy_pass http://lich; 
proxy_http_version 1.1; 
proxy_set_header Connection "";

官方文档在这里:http://nginx.org/en/docs/http/ngx_http_upstream_module.html 
官方文档中说:proxy_http_version和proxy_set_header这两个配置是需要加上的。
不建议使用http 1.0通过Connection:Keep-Alive的方式。

配置完成之后重新测试,qps略微有一点提升。 但并不明显。 为了验证长连接是否生效, 同样通过 netstat命令查看连接。 发现连接到后端8081端口的nginx开启的临时端口不停的发生变化, 这证明了仍然是在采用短链接的方式。 那么是谁先关闭连接的呢。 

通过tcpdump抓包发现, 首先发出 Fin 包的是tomcat。 也就是说, tomcat主动关闭的连接。

 

原来在tomcat的配置文件中, 有关于keepalive的几个参数。 包括每一个连接完成多少个http请求之后就关闭等。 详细的参数可以参见tomcat的文档。详细的文档应该看这里:https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

对tomcat的connector进行了一些调整(包括maxKeepAliveRequests和keepAliveTimeout两个参数,都设置成-1)之后, 再看连接,已经不会频繁断开并重建了。 QPS也提升到了900+.

尽管如此, nginx仍然是瓶颈,worker_processes设置为4个的时候,cpu可以利用到100%, QPS可以达到1200.

最后再做一个对比, 当jmeter绕过nginx,不走https而直接访问http的端口8081时,qps可以达到1500+。对比一下,对https的开销大概有个概念。

(转)一次压测对nginx/tomcat配置的调整

标签:第一个   反向代理   gre   mysq   一点   文档   默认   nginx   netstat命令   

原文地址:https://www.cnblogs.com/zichuan/p/9057038.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!