apache-2.2 – 使用nginx进行负载均衡时,每秒请求速度较慢

我已经将nginx设置为负载均衡器,可以将代理请求转发给2台Apache服务器.我已经使用ab对设置进行了基准测试,并且在2个后端服务器之间分配请求(不使用ip_hash),每秒获得大约35个请求.令我困惑的是,如果我直接通过ab查询任一后端服务器,我每秒会得到大约50个请求.

我已经在ab中尝试了许多不同的值,最常见的是具有100个并发连接的1000个请求.

知道为什么分布在两台服务器上的流量会导致每秒的请求数量少于直接命中的数量吗？

Additional info:

我已经尝试了1到8之间的worker_processes值,1024和8092之间的worker_connections,并且还尝试了keepalive 0和65.

我的主要conf目前看起来像这样：

user www-data;
worker_processes 1;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

worker_rlimit_nofile 8192;

events {
    worker_connections  2048;
    use epoll;
}

http {
    include       /etc/nginx/mime.types;

    sendfile        on;

    keepalive_timeout  0;
    tcp_nodelay        on;

    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

我有一个虚拟主机(在可用的站点中),可以将本地网络中的所有内容重定向到/后端的2个后端.

最佳答案

并发是我的第一个想法,因为ab中的默认并发是一个,添加负载均衡器总是会增加请求的延迟,但是你提到你将并发设置为100,所以这不应该是原因.

反向代理可能会为每个请求添加标头.这使得使用nginx时的响应略大于不使用时的响应.如果您通过千兆位内部网络运行此操作可能是一种难以察觉的变化,但如果您从办公室或家中运行此更改,特别是如果您使用小文件进行此测试,则额外数据可能会导致可测量的差异.当然,小文件在网络上非常正常,因此小文件可能会产生更实际的基准.

缓存也可以对后续运行产生影响,具体取决于运行基准测试的方式.这将使您的第一次运行比之后的所有运行慢.在负载平衡时,这进一步复杂化,因为有两倍的预热缓存.如果你先测试nginx,那可能会造成不同.您可以通过关闭所有缓存或忽略您执行的第一次运行来缓解此问题.获取所有缓存非常困难,有些可能甚至不在您的控制之下.我赞成忽略首先运行的方法.您提到您已经使用不同的值完成了多次运行,但是为避免基于缓存的不准确性,您需要做的是连续两次或多次运行完全相同的基准测试并忽略第一次运行.

另一件可能导致此类行为的事情是在系统中的其他位置锁定.通过“锁定”,我指的是一次只能使用其中一个Web服务器的资源.这方面的一个例子是将PHP会话存储在数据库的MyISAM表中.对PHP页面的每个请求要么在此表上执行读取请求以查找会话,要么创建新会话的写入请求.由于MyISAM表具有表级锁定,因此在任何给定时间只有一个Web服务器可以使用此表,并且由于每个页面都必须使用此表,这可以抵消完全拥有两个Web服务器的优势.系统其余部分越快,锁的相对影响就越大.
它也不必是数据库,它可以是SAN或NAS上的共享webroot,因此即使是静态文件也不能免于此类问题.
您没有在原始问题中提及任何其他系统,但随着系统的增长,这个问题很可能会出现.

最后,对基准测试的一般建议有点(它变成了很多).您获得特定速度(或此类基准测试的每秒请求数)的原因始终是由于一个瓶颈. Apache基准测试将尽可能快地请求,直到某些资源达到100％利用率.此资源可能是Web服务器中的CPU,也可能是反向代理服务器中的CPU.但是,这不太可能.在CPU速度成为问题之前,磁盘访问和网络带宽(内部和外部)通常是您遇到的第一个瓶颈.即使您看到使用率为90％的资源,这也不是瓶颈.在100％的某个地方会有另一个阻止这个高于90％. 100％的那个可能在不同的系统上,它可能不是您拥有的系统.它可以是网络,这意味着特定设备,如交换机或NIC,甚至是网络中的电缆.

要找到真正的瓶颈,你应该从你可以衡量的一些价值开始(比如,当前活跃的nginx工人的数量)并问“为什么这不会更高？”如果它已达到其最大值,那么您已找到瓶颈.如果没有,您应该看的下一个地方是连接请求.无论你是上游还是下游都是本能的问题.在下游,nginx将要求网络插槽将请求传递给Apache.问问自己,开放网络连接的数量是否达到最大值.然后是NIC的带宽.然后是网络的带宽.然后是Apache机器的NIC带宽.如果答案很明显,你可以跳过其中的一些步骤,但不要随便猜测你的系统.让你的任务有序且符合逻辑.

有时,您遇到的瓶颈将出现在您正在运行的机器上.当发生这种情况时,基准测试毫无意义.您测试的只是您正在运行的机器或网络的速度.您可以获得与您的网站相同的Google搜索结果.为了确保您拥有有意义的基准,您必须在基准测试运行时找到瓶颈. (或者至少确保它不在测试机器上.)为了提高站点的基准,有必要找到系统中的瓶颈并加宽它,这在基准运行时最容易做到.

测试像你这样的大型系统意味着瓶颈可以隐藏的地方数量非常大.有时它可以帮助您将基准范围缩小到系统的几个部分.削减nginx并转向Apache就是其中的一个例子,并且在与Web服务器相同的网络中运行您的基准测试是另一个例子.但是您可以进一步测试各个组件,例如磁盘,网络和RAM延迟和吞吐量.

不幸的是,并非所有资源都有很好的容易百分比报告CPU和RAM的使用方式.例如,将大文件写入磁盘可能会达到40MB / s但是当写入大量小文件并同时读回它们时(例如存储在磁盘上的PHP会话),您可能会获得10MB / s.为了找到资源的真实大小,您必须单独在系统的每个部分上运行基准测试.不要因为你有一个千兆交换机就假设你的内部网络将获得1000Mb / s的速度. IP,TCP和应用程序级标头(如NFS标头)都可以降低此基准,因为可以降低NIC和电缆的速度.硬件错误也会影响各种基准测试,而硬件仍在运行但低于制造商的规格.

瓶颈可能在nginx机器上.如果是这样,负载平衡解决方案比直接单服务器慢的原因应该是显而易见的.在这一点上,rmalayter的一些建议会很好.直到你知道瓶颈在哪里,你只是猜测,我们也是.如果瓶颈在其他地方,你应该找到它,然后回到这里寻找或询问更具体的问题.