欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

记一次压力测试和对nginx/tomcat配置的调整

来源:本站整理 作者:佚名 时间:2014-04-25 TAG:压力测试 nginx tomcat 我要投稿

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

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

在一个名为“测试”的测试计划下, 我们建立了一个线程组。 这个线程组可以设置线程数,创建时间(在多长时间内创建出这么多个线程),每个线程任务循环执行次数。 然后为这个线程组指派了一个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开启的临时端口不停的发生变化, 这证明了仍然是在采用短链接的方式。 那么是谁先关闭连接的呢。 

[1] [2]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载