ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

nginx网关服务器性能要求,网关服务:zuul与nginx的性能测试对比

2022-11-06 13:48:11  阅读:206  来源: 互联网

标签:数据 浏览器 工具 导出 管理 结构


案例一. Nginx单工做线程,单文件路径访问测试html

文件内容仅6个数字:123456nginx

测试命令:ab -c 100 -n 500000 127.0.0.1:80/html/test.htmlapi

能够看到每秒并发:32566 reqtomcat

使用top命令,能够看到cpu使用状况: ab cpu:99% nginx cpu:99%服务器

server {

listen 80;

location / {

proxy_pass http://127.0.0.1:8080/;

}

}架构

server {

listen 8080;

location /html/ {

alias /data/service/gw/html/;

expires 7d;

}

}负载均衡

命令:ab -c 100 -n 500000 127.0.0.1:80/html/test.html

能够看到并发一样能够达到34497req

而负载状况:

网关nginx,用了两个工做线程,总cpu占用率:95.7%+95.3%=191%

而本地文件访问nginx,仅一个工做线程,cpu占用率:90%

因为此时zuul是多线程的架构,很依赖cpu资源大小,这里先作第一组配置测试:8u cpu, 16GB 内存。

zuul的线程配置:最小min-space-threads:100,最大max-threads:200

使用命令: ab -c 200 -n 300000 127.0.0.1:8000/api/html/test.html

并发数大约在12860req/s

稳定以后整个系统的用户空间加内核空间的总负载基本约77.7%=58.7%+19%

内存使用状况以下:

能够分析到此时系统很忙碌,基本是满负荷在运行,瓶颈在cpu资源的竞争上。

案例四:将案例三的状况作第二组配置的测试:12u cpu, 24GB 内存。

ab -c 100 -n 500000 127.0.0.1:8000/api/html/test.html

并发数据果真有对应核数的比例提高:19113req/s

此时系统也处于比较高的负载:73.6=60.1+13.5,其中用户空间一样占到大约60.1%的负载

而内存仍是有不少富余的,性能瓶颈一样是在cpu资源的竞争上。

总结:

在cpu资源相对充足的状况下,zuul的性能也是不俗的,单个实例一样能够达到1W+,cpu的占用大概在500%。

这里可能还能够用jvm等参数进行调优,也欢迎在此基础之上性能调优作得更细致的朋友前来指教,但整体性能指标相差不会太远,而zuul是能够很方便的支持多个实例横向扩展以及路由的负载均衡的,在分布式的架构演进上面做为网关层是一个比较不错的选择。

最后附上zuul的jmc性能监控图:

线程状况

也能够从jmc的线程视图中能够观察到,有大量的tomcat的任务线程在竞争任务队列的资源,并处于等待当中。

cpu占用率最多的线程固然仍是属于网络io的链接线程,以及读写数据事件线程。

内存使用状况:

案例一. Nginx单工做线程,单文件路径访问测试html 文件内容仅6个数字:123456nginx 测试命令:ab -c 100 -n 500000 127.0.0.1:80/html/test.htmlapi 能够看到每秒并发:32566 reqtomcat 使用top命令,能够看到cpu使用状况: ab cpu:99% nginx cpu:99%服务器 server { listen 80; location / { proxy_pass http://127.0.0.1:8080/; } }架构 server { listen 8080; location /html/ { alias /data/service/gw/html/; expires 7d; } }负载均衡 命令:ab -c 100 -n 500000 127.0.0.1:80/html/test.html 能够看到并发一样能够达到34497req 而负载状况: 网关nginx,用了两个工做线程,总cpu占用率:95.7%+95.3%=191% 而本地文件访问nginx,仅一个工做线程,cpu占用率:90% 因为此时zuul是多线程的架构,很依赖cpu资源大小,这里先作第一组配置测试:8u cpu, 16GB 内存。 zuul的线程配置:最小min-space-threads:100,最大max-threads:200 使用命令: ab -c 200 -n 300000 127.0.0.1:8000/api/html/test.html 并发数大约在12860req/s 稳定以后整个系统的用户空间加内核空间的总负载基本约77.7%=58.7%+19% 内存使用状况以下: 能够分析到此时系统很忙碌,基本是满负荷在运行,瓶颈在cpu资源的竞争上。 案例四:将案例三的状况作第二组配置的测试:12u cpu, 24GB 内存。 ab -c 100 -n 500000 127.0.0.1:8000/api/html/test.html 并发数据果真有对应核数的比例提高:19113req/s 此时系统也处于比较高的负载:73.6=60.1+13.5,其中用户空间一样占到大约60.1%的负载 而内存仍是有不少富余的,性能瓶颈一样是在cpu资源的竞争上。 总结: 在cpu资源相对充足的状况下,zuul的性能也是不俗的,单个实例一样能够达到1W+,cpu的占用大概在500%。 这里可能还能够用jvm等参数进行调优,也欢迎在此基础之上性能调优作得更细致的朋友前来指教,但整体性能指标相差不会太远,而zuul是能够很方便的支持多个实例横向扩展以及路由的负载均衡的,在分布式的架构演进上面做为网关层是一个比较不错的选择。 最后附上zuul的jmc性能监控图: 线程状况 也能够从jmc的线程视图中能够观察到,有大量的tomcat的任务线程在竞争任务队列的资源,并处于等待当中。 cpu占用率最多的线程固然仍是属于网络io的链接线程,以及读写数据事件线程。 内存使用状况:

标签:数据,浏览器,工具,导出,管理,结构
来源:

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有