我们有一个运行Nginx和Gunicorn的Web服务器设置,它运行Django应用程序.曾经有一段时间我们获得了很高的负载并获得了大量的5XX.为了摆脱这种情况,我们立即增加了5次服务器数量,并重新启动了所有Gunicorn工作人员.现在,我们的服务器仍未得到最佳使用,CPU使用的最大值为10-15%,内存相同(20-30%).因此,这不是一个永久的解决方案,如果我们使用更大和更多的服务器,它也会导致我们的停机时间和高成本.
为了研究这个,我们从负载测试开始.
当我们进行负载测试时,即使服务器上的资源几乎没有使用,我们也会开始收到5xx错误.
负载测试1
资源:1个ELB 1服务器,Nginx和4个gunicorn工作者在虚拟环境中运行Django.
使用Locust进行负载测试,它具有用户在进入应用程序后将执行的完整工作流程.
1000名用户,增加10
每秒请求数(失败前): CloudWatch上的最大CPU = 45%,服务器上的波动率高达100%在负载测试开始后,内存的使用量不超过2 GB.服务器有8 GB内存(RAM)
突然间我开始出错了.开始获取网关超时,无法连接到后端服务器.还有AWS ELB 5xx,然后服务器也停止服务.
负载测试2
资源:4个服务器,1个ELB,Nginx和4个Gunicorn工作人员在服务于Django的virtualenv中的每个服务器上运行.
1000名用户,增加10
34 RPS,11%突然失败率然后停止获得200. ELB服务器停止运行.总共29000个请求,2965个失败我相信然后都开始失败.请求大小约为140688 Bytes.开始获取网关超时,无法连接到后端服务器.
CPU再次没有超过20%的利用率.负载测试开始后,内存的使用量不超过2 GB.服务器有8 GB内存(RAM)
负载测试3 资源:一个ELB下的11个服务器
直到80-200 RPS波动(每秒请求数)开始获取网关超时,无法连接到后端服务器服务器不健康
CPU再次没有超过20%的利用率.负载测试开始后,内存的使用量不超过2 GB.服务器有8 GB内存(RAM)
负载测试4
资源:40台服务器类似线路的结果.
允许每个工作人员接受1500个连接和微调fds,缓存,gzip,工作者限制等.
对Nginx conf进行了以下更改:
Nginx worker processes are set to auto which is okay, I guess.
Nginx keepalive timeout is 65 which is high.
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
tcp_nopush=on …