点赞
评论
收藏
分享
举报
NGINX Plus 选型指南:我们如何进行测试
发表于2020-12-24 16:47

浏览 467

今年早些时候,我们对 NGINX Plus 的性能进行了基准测试,并创建了一份选型指南,为将其部署到裸机服务器上提供指导。NGINX Open Source 和 NGINX Plus 广泛应用于7 层负载均衡,亦称为应用负载均衡


[编者按语–我们会定期更新选型指南,以及时反映 NGINX Plus 功能以及硬件成本和性能方面的变化。上述链接始终指向最新指南。

如欲了解 NGINX  NGINX Plus 作为 Web 服务器的性能信息,请参阅测试 NGINX 和 NGINX Plus Web 服务器的性能。]


这份选型指南概述了在各种尺寸的服务器上运行的 NGINX Plus 有望实现的性能(在选型指南中您可以查询到在不同资源下NGINX Plus的预期性能),以及估计的硬件成本。您可以参考这份选型指南选定适当的 NGINX Plus 部署,以便尽可能地避免过度配置(这会造成高成本问题)或配置不足(这会导致性能问题,并且从长远来看将造成高成本问题并且从长远来看反而会导致使用成本增高)。


不少客户以及其他想要再现我们成果的人士对这份选型指南以及我们所使用的方法颇感兴趣(不少客户及潜在使用者对该指南以及我们所使用的方法颇感兴趣)。这篇博文概述了我们为实现选型指南中所示结果所执行的测试。它涵盖了我们使用的拓扑结构和运行的测试,并介绍了我们是如何确定选型指南中的标价的。


注意:尽管这份选型指南是专为 NGINX Plus 开发的,但是在测试中我们使用的是 NGINX Open Source(开源版NGINX),此举支持任何人,无论是否订阅 NGINX Plus,都可以复现我们的测试。而且,测试不涉及 NGINX Plus 的任何增强功能,因此无论是对 NGINX Open Source(开源版NGINX) 还是对 NGINX Plus 进行测试,结果都是相同的。NGINX Open Source 版本 (NGINX开源版本)1.9.7 大致对应 NGINX Plus 版本 7。

不过,为了在测试拓扑结构中更好地将反向代理与后端 Web 服务器区分开来,我们将 NGINX Plus 称为前者,将 NGINX (Open Source) (开源版NGINX)称为后者。


拓扑结构

所有测试都是使用三台独立的计算机完成的,这些计算机通过简单的2 层扁平网络连接到双 40 GbE 链路。


使用标准的连续客户端-代理-web server拓扑结构架构来测试 NGINX Plus 性能

为了从客户端计算机生成流量,我们使用了 wrk,一款类似于 ab (ApacheBench) 的性能测试工具。如图所示,所有流量都定向到 NGINX Plus 反向代理,该代理将连接转发到开源版 NGINX Open Source Web 服务器后端。


所用硬件

我们使用以下硬件进行了测试。

计算机

CPU

网络

内存

客户端

2 颗英特尔 (R) 至强 (R) CPU E5‑2699 v3 @ 2.30GHz,36 个真正(或 72 HT)内核

2 个英特尔 XL710 40GbE QSFP+(版本 01)

16 GB

反向代理

2 颗英特尔 (R) 至强 (R) CPU E5‑2699 v3 @ 2.30GHz,36 个真正(或 72 HT)内核

4 个英特尔 XL710 40GbE QSFP+(版本 01)

16 GB

Web 服务器

2 颗英特尔 (R) 至强 (R) CPU E5‑2699 v3 @ 2.30GHz,36 个真正(或 72 HT)内核

2 个英特尔 XL710 40GbE QSFP+(版本 01)

16 GB


所用软件

我们使用以下软件进行了测试:

• 在客户端计算机上运行的 wrk 版本 4.0.0 生成 NGINX 代理的流量。 我们根据这些说明进行了安装。

• NGINX Open Source 开源版本 1.9.7 在反向代理和 Web 服务器计算机上运行。 在反向代理和 Web 服务器上运行NGINX 1.9.7开源版本。我们根据这些说明,从位于 nginx.org 的官方存储库中进行了安装。

Ubuntu Linux 14.04.1 在所有三台计算机上运行。三台服务器运行的系统版本是Ubuntu Linux 14.04.1


测试方法

我们使用不同数量的 CPU 测试了 NGINX Plus 反向代理服务器的性能。一个 NGINX Plus worker 进程消耗一颗CPU,因此为了测量不同数量 CPU 的性能,我们改变了 worker 进程的数量,使用两个、四个、八个 worker 进程重复进行了测试。有关 NGINX 架构的概述,请参阅我们的博客。

注意:如欲手动设置 worker 进程数,请使用 worker_processes 指令。 默认值为 auto,这表示 NGINX Plus 会检测 CPU 数量并为每颗 CPU 运行一个 worker 进程。


性能指标

我们对以下指标进行了测量:

每秒请求数 (RPS) – 测量处理每秒 HTTP 请求的能力。在我们的测试中,每个客户端都通过 keepalive 连接发送对 1 KB 文件的请求。反向代理会处理每个请求,并通过另一个 keepalive 连接将其转发到 Web 服务器。

每秒 SSL/TLS 事务 (TPS) –测量处理每秒新建 SSL/TLS 连接的能力。在我们的测试中,每个客户端都会通过新连接发送一系列 HTTPS 请求。反向代理解析请求,然后通过建立的 keepalive 连接将这些请求转发到 Web 服务器。Web 服务器会就每个请求返回 0 字节响应。

吞吐量 – 测量 NGINX Plus 通过 HTTP 为 1 MB 文件提供服务时可维持的吞吐量。


运行测试

为了生成所有客户端流量,我们在使用 wrk 时用到了以下选项:

• -c 选项指定了要创建的 TCP 连接数量,在我们的测试中,我们将其设置为 50 个连接。

• -d 选项指定了生成流量的用时周期。我们的每项测试均持续了 3 分钟。

• -t 选项指定了要创建的线程数量。我们指定了一个线程。

为了充分利用每颗 CPU,我们使用了任务集,该任务集可以将单个 wrk 进程绑定到 CPU 上。与增加 wrk 数量的做法相比,该方法能够产生更加一致的结果。


每秒请求数

为了测量每秒请求数 (RPS),我们运行了以下脚本:

for i in `seq 1 number-of-CPUs`; do

    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1kb.bin &

done

该测试为每个 CPU 生成一个 wrk 副本,总共为我们的客户端计算机生成了 36 个副本。每个副本创建了 50 个 TCP 连接,并通过这些连接对 1 KB 文件发起了长达 3 分钟(180 秒)的连续请求。

每秒 SSL/TLS 事务

为了测量每秒 SSL/TLS 事务 (TPS),我们运行了以下脚本:

for i in `seq 1 number-of-CPUs`; do

    taskset -c $i wrk -t 1 -c 50 -d 180s -H 'Connection: close' https://Reverse-Proxy-Server-IP-address/0kb.bin &

done

该测试使用了与上一个测试相同的 -c、-d 和 -t 数值参数,但其重点是处理 SSL/TLS 连接,因此与上一个测试存在两方面的显著差异:

• 客户端打开并关闭每个请求的连接(-H 选项设置  Connection: close HTTP 标头)。

• 所请求的文件大小为 0(零)字节,而不是 1 KB。


吞吐量

为了测量吞吐量,我们运行了以下脚本:

for i in `seq 1 number-of-CPUs`; do

服务器型号

规格

价格

Dell PowerEdge R230

CPU:2 个内核 英特尔酷睿 I3 6100 3.7GHz,2C/4T
RAM:4 GB
HDD:500 GB
网卡:英特尔 X710 2×10 Gbe

1,200 美元

CPU:英特尔® 至强® E3‑1220 v5 3.0GHz,4C/8T
RAM:4 GB
HDD:500 GB
网卡:英特尔 XL710 2×40 Gbe

1,400 美元

Dell PowerEdge R430

CPU:英特尔® 至强® E5‑2630 v3 2.4GHz,8C/16T
RAM:4 GB
HDD:500 GB
网卡:英特尔 XL710 2×40 Gbe

2,200 美元

CPU:2 颗英特尔® 至强® E5‑2630 v3 2.4GHz,8C/16T
RAM:8 GB
HDD:500 GB
网卡:英特尔 XL710 2×40 Gbe

3,000 美元

Dell PowerEdge R630

CPU:2 颗英特尔® 至强® E5‑2697A v4 2.6GHz,16C/32T
RAM:8 GB
HDD:500 GB
网卡:英特尔 XL710 2×40 Gbe

8,000 美元

CPU:2 颗英特尔® 至强® E5‑2699 v3 2.3GHz,18C/36T
RAM:8 GB
HDD:500 GB
网卡:英特尔 XL710 2×40 Gbe

11,000 美元

    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1mb.bin &

done


与第一个测试的唯一区别是文件较大,为 1 MB。当文件大小为1MB时测试结果与第一次测试不同,我们发现使用更大的文件(10 MB)不会增加整体吞吐量。


多个网卡

在我们的测试中,我们使用了多个网卡。以下经过稍微修改的脚本,可确保流量在两张网卡之间平均分配:

for i in `seq 1 number-of-CPUs/2`; do

    n=`echo $(($i+number-of-CPUs/2))`;

    taskset -c $i ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-1/1kb.bin &

    taskset -c $n ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-2/1kb.bin &

done


定价

获得不同内核数量的性能数据之后,最后一步,就是确定相应规格的服务器的成本。我们使用了规格类似于我们测试用英特尔硬件的 Dell PowerEdge 服务器的价格。针对本次测试环境,我们以Dell PowerEdge 服务器的价格作为参考。下面的附录包含每个服务器的完整物料清单,以及反向代理和 Web 服务器 的完整 NGINX 配置。


附录

Dell 硬件配置

选型指南中的价格适用于以下 Dell 硬件配置。

注意:指南中所示规格和价格的服务器型号在我们运行测试时提供,日后的规格与价格可能会有变化。 以下Dell服务器规格及价格信息仅供参考,最终采购价格以服务器厂商实际报价为准。

服务器型号

规格

价格

Dell PowerEdge R230

CPU:2 个内核 英特尔酷睿 I3 6100 3.7GHz,2C/4T
RAM:4 GB
HDD:500 GB
网卡:英特尔 X710 2×10 Gbe

1,200 美元

CPU:英特尔® 至强® E3‑1220 v5 3.0GHz,4C/8T
RAM:4 GB
HDD:500 GB
网卡:英特尔 XL710 2×40 Gbe

1,400 美元

Dell PowerEdge R430

CPU:英特尔® 至强® E5‑2630 v3 2.4GHz,8C/16T
RAM:4 GB
HDD:500 GB
网卡:英特尔 XL710 2×40 Gbe

2,200 美元

CPU:2 颗英特尔® 至强® E5‑2630 v3 2.4GHz,8C/16T
RAM:8 GB
HDD:500 GB
网卡:英特尔 XL710 2×40 Gbe

3,000 美元

Dell PowerEdge R630

CPU:2 颗英特尔® 至强® E5‑2697A v4 2.6GHz,16C/32T
RAM:8 GB
HDD:500 GB
网卡:英特尔 XL710 2×40 Gbe

8,000 美元

CPU:2 颗英特尔® 至强® E5‑2699 v3 2.3GHz,18C/36T
RAM:8 GB
HDD:500 GB
网卡:英特尔 XL710 2×40 Gbe

11,000 美元


NGINX Plus 反向代理配置

在 NGINX Plus 反向代理上使用了以下配置。请注意 keepalive_timeoutkeepalive_requests 这两个指令集:

  • • 对于 SSL/TLS TPS 测试,我们设置了两个指令的数值,以确保连接仅面向一个请求保持打开,因为该测试的目标是查看 NGINX Plus 每秒可以处理的 SSL/TLS 连接数量。SSL/TLS 会话缓存也被禁用。
  • • 在 RPS 测试中,对指令进行了微调,以确保连接维持尽可能长的时间。

否则,该配置会是相当标准的反向代理服务器配置,其中 NGINX Plus 会使用 proxy_pass 指令代理到 Web 服务器。

user                 nginx;

worker_processes     auto;

worker_rlimit_nofile 10240;

pid                  /var/run/nginx.pid;


events {

    worker_connections 10240;

    accept_mutex       off;

    multi_accept       off;

}


http {

    access_log    off;

    include       /etc/nginx/mime.types;

    default_type  application/octet-stream;


    log_format main '$remote_addr - $remote_user [$time_local] "$request" '

                    '$status $body_bytes_sent "$http_referer" '

                    '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '

                    '"$ssl_protocol" ';


    sendfile on;


    # RPS tests

    keepalive_timeout  300s;     

    keepalive_requests 1000000;


    # SSL/TLS TPS tests

    #keepalive_timeout  0;  

    #keepalive_requests 1; 

    upstream webserver {

        server Web-Server-IP-address;

    }


    server {

        listen 80;

        listen 443 ssl backlog=102400 reuseport;


        ssl_certificate     /etc/nginx/ssl/rsa-cert.crt;

        ssl_certificate_key /etc/nginx/ssl/rsa-key.key;

        ssl_session_tickets off;

        ssl_session_cache   off;


        root /var/www/html;

            location / {

                proxy_pass http://webserver;

            }

        }

    }

}



NGINX Web 服务器配置

在 NGINX Web 服务器上使用了以下配置。正如 root指令所配置,它使用 /var/www/html/ 下的静态文件。该静态文件是使用 dd 生成的;本示例创建一个 1 KB 的零zero文件:

dd if=/dev/zero of=1kb.bin bs=1KB count=1

The configuration:配置如下:

user                 nginx;

worker_processes     auto;

worker_rlimit_nofile 10240;

pid                  /var/run/nginx.pid;


events {

    worker_connections 10240;

    accept_mutex       off;

    multi_accept       off;

}


http {

    access_log   off;

    include      /etc/nginx/mime.types;

    default_type application/octet-stream;


    log_format main '$remote_addr - $remote_user [$time_local] "$request" '

                    '$status $body_bytes_sent "$http_referer" '

                    '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '

                    '"$ssl_protocol" ';


    sendfile on;


    keepalive_timeout  300s;     

    keepalive_requests 1000000;


    server {

        listen 80;

        root /var/www/html;

    }

}


如欲试用 GINX Plus,如需使用NGINX Plus,请立即下载 30 天免费试用版,或与我们联系以讨论您的用例



已修改于2023-03-05 02:20
本作品系原创
创作不易,留下一份鼓励
NGINX官方账号

暂无个人介绍

关注



写下您的评论
发表评论
全部评论(0)

按点赞数排序

按时间排序

关于作者
NGINX官方账号
这家伙很懒还未留下介绍~
171
文章
21
问答
180
粉丝
相关文章
概述这几篇博客文章我们将会重点分析nginx配置项解析的原理。因为nginx配置框架设计的非常灵活和强大,这就使得我们在分析其内部机制的时候带来了不小的挑战,而这个系列的博客的意义就在于梳理其内部实现,并整理出大致框架,以分享给读者。作者之前看过网上的一些博客写的关于nginx配置框架的梳理,粗制滥造,因此萌生了自己写的想法。希望大家能提出宝贵意见。在讲配置之前,我们不得不简单说下nginx模块的概念。因为nginx属于微内核设计,nginx的强大之处在于灵活的微内核再加上可扩展的模块,nginx自身的模块有core、event、http、mail等核心模块,但是开发者又可以基于这些核心模块开发满足自身业务需求的模块,首当其冲的便是http模块了,因此,大家在阅读nginx代码的时候可以看到很多的ngx_http_xxx,这些都是基于http模块开发的第三方模块,而我们后面局里的重点也将会是http,谁叫他这么重要呢。好了,言归正传,我们来看看nginx如何管理复杂的配置项吧。我在这里假设各位看官对nginx配置项的形式有了初步的了解,如果还没有配置过nginx的,那么请先移步,自行脑
点赞 0
浏览 439
原文作者:BrianEhlertofF5原文链接:Kubernetes网络入门-NGINX转载来源:NGINX官方网站  NodePort、LoadBalancer、Ingresscontroller(Ingress控制器)……,Kubernetes组件简直令人眼花缭乱。当我们与客户和社区讨论生产级Kubernetes部署时,他们经常会问的一个问题是:我需要Ingresscontroller吗?这个问题不能简单地用“是”或“否”来回答,我们要先了解将流量路由到pod的几种不同方式。本文介绍了Kubernetes网络的基础知识,可帮助您就是否以及何时需要Ingresscontroller做出明智的决策。Kubernetes提供了多种方法和层级用于将外部流量路由到pod——但它们各有不同。默认的模型是 kube-proxy,不过它既不是代理,也不是为实施流量负载均衡、控制API或监控service行为而设计。幸运的是,我们还可以使用其他方法来管理外部流量。但在展开讨论之前,我们先来快速回顾一下Ku
点赞 0
浏览 726
目录问题背景解决思路网络拓扑搭建Macvlan命名空间测试命名空间网络连通性启动nginx服务结语1、问题背景  一种多租户多Nginx集群部署的上云解决方案示意图如图1所示:图1一种多租户多Nginx集群部署示意图  该方案主要包含三部分,分别为APIServer,配置中心及集群部署节点,各部分实现的功能为:APIServer:Nginx集群服务的总入口,负责接收各类管控信息,并将请求信息解析后转发至配置中心;配置中心:负责不同租户Nginx实例的安装部署与配置管理;集群部署节点:不同租户在不同节点上部署Nginx实例,实现实例级别的高可用;  如图1所示,要实现高可用的部署方式,就要求在每一个服务器node节点上部署的Nginx实例分属于不同的租户;要实现每个node节点的Nginx实例分属于不同的租户,就要求在node节点实现租户隔离。这里的租户隔离至少需要包含两个属性,一个是网络资源的隔离,一个是Nginx实例端口占用的隔离。2、解决思路为了在同一台node节点实现租户隔离,目前常见的有以下几
点赞 1
浏览 371