网关服务:zuul与nginx的性能测试对比

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

文件内容仅6个数字:123456

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

可以看到每秒并发:32566 req

使用top命令,可以看到cpu使用情况: ab cpu:99%    nginx cpu:99%

 

案例二. Nginx作为入口网关,将请求转发至业务服务,这里为了方便,直接使用nginx作为业务服务

第一级接入层网关nginx转发配置,端口80:

server {
        listen    80;
        location / {
                proxy_pass   http://127.0.0.1:8080/;
        }
}

转发至第二级http业务服务8080,nginx配置如下,这里简单访问本地文件:

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,第二级仍然转发至业务http nginx服务器,业务请求简单访问本地文件

由于此时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的连接线程,以及读写数据事件线程。

内存使用情况:

 

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页