nginx网关服务器性能要求,网关服务：zuul与nginx的性能测试对比
作者：互联网
案例一. 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的链接线程，以及读写数据事件线程。 内存使用状况：