Nginx 使用带有 Gunicorn 的 Django 发送网络响应花费的时间太长
Nginx takes too long to send the network response using Django with Gunicorn
我正在使用 Django 开发 Web 应用程序,到目前为止一切正常,但我的服务器响应有一个大问题,通常我第一次想进入它需要大约 20 到 40 秒从服务器获取响应。
我使用的是 Linode linux 虚拟机 运行 Ubuntu 18.04,是目前非常便宜的计划,只有一个内核 CPU,2GB 的ram 和 50Gb 的 SSD 存储,但是因为我是唯一访问该网站的人,所以我觉得它需要这么长时间来响应是不正确的(每次我重新启动 nginx 或 gunicorn 时,或者在一段时间不活动后,它都会发生,响应后开始以正常速度工作。
我使用 chrome 开发工具制作了性能记录,这些是我的结果:
Network result
如您所见,网络请求花费了 22 秒,如果我检查主线程,我可以看到 chrome 检测到该时间为空闲,而服务器处理视图所花费的实际时间只有几毫秒。
Chrome results
我的服务器也有 SSL 证书,nginx 的配置如下:
upstream rienpaAdmin {
server 127.0.0.1:8000 fail_timeout=0;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
ssl on;
ssl_certificate /correct/path/certificate.crt;
ssl_certificate_key /correct/path/certificate.key;
server_name lodugo.com www.lodugo.com;
client_max_body_size 4G;
access_log /var/www/rienpaAdmin/nginx-access.log;
error_log /var/www/rienpaAdmin/nginx-error.log;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /var/www/rienpaAdmin;
}
location / {
include proxy_params;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
proxy_buffering off;
proxy_headers_hash_max_size 512;
proxy_headers_hash_bucket_size 128;
proxy_pass http://unix:/run/gunicorn.sock;
}
}
server {
listen 80;
listen [::]:80;
server_name lodugo.com www.lodugo.com;
return 301 https://$server_name$request_uri;
}
我有这样的 gunicorn 服务和套接字:
套接字:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
服务:
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/rienpaAdmin
ExecStart=/var/www/rienpaAdmin/adminPython/bin/gunicorn \
--access-logfile - \
--workers 3 \
--threads 1 \
--bind unix:/run/gunicorn.sock \
rienpaAdmin.wsgi:application
[Install]
WantedBy=multi-user.target
任何人都可以给我一个很好的解释,为什么会这样?我可以升级我的 Linode 服务器,但我真的觉得我当前的一个用户设置应该像第一次请求后一样快速响应,我有几天阅读其他问题,但其中 none 确实帮助我解决了这个问题。
以防万一,我将 Django 3.0 与 postgreSQL 数据库一起使用
编辑:
其中一个答案说我有两个不同 IP 的 A 记录,这是我的 NameCheap 域的 DNS 配置的屏幕截图
你知道你的域名有2条A记录吗?
$ dig lodugo.com
...
;; ANSWER SECTION:
lodugo.com. 1308 IN A 192.64.119.241
lodugo.com. 1308 IN A 45.56.114.74
DNS 服务器将依次响应每个 IP 地址。我怀疑只有一个地址是正确的,所以有 50% 的机会得到一个最终超时的错误地址,然后可能会重试。
这符合我所看到的 - 通常需要很长时间才能连接,但是一旦您输入正确的地址,它就会给出快速响应,直到 DNS 记录到达其 TTL 的末尾。那时你有 50% 的机会再次出现。
我正在使用 Django 开发 Web 应用程序,到目前为止一切正常,但我的服务器响应有一个大问题,通常我第一次想进入它需要大约 20 到 40 秒从服务器获取响应。
我使用的是 Linode linux 虚拟机 运行 Ubuntu 18.04,是目前非常便宜的计划,只有一个内核 CPU,2GB 的ram 和 50Gb 的 SSD 存储,但是因为我是唯一访问该网站的人,所以我觉得它需要这么长时间来响应是不正确的(每次我重新启动 nginx 或 gunicorn 时,或者在一段时间不活动后,它都会发生,响应后开始以正常速度工作。
我使用 chrome 开发工具制作了性能记录,这些是我的结果:
Network result
如您所见,网络请求花费了 22 秒,如果我检查主线程,我可以看到 chrome 检测到该时间为空闲,而服务器处理视图所花费的实际时间只有几毫秒。
Chrome results
我的服务器也有 SSL 证书,nginx 的配置如下:
upstream rienpaAdmin {
server 127.0.0.1:8000 fail_timeout=0;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
ssl on;
ssl_certificate /correct/path/certificate.crt;
ssl_certificate_key /correct/path/certificate.key;
server_name lodugo.com www.lodugo.com;
client_max_body_size 4G;
access_log /var/www/rienpaAdmin/nginx-access.log;
error_log /var/www/rienpaAdmin/nginx-error.log;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /var/www/rienpaAdmin;
}
location / {
include proxy_params;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
proxy_buffering off;
proxy_headers_hash_max_size 512;
proxy_headers_hash_bucket_size 128;
proxy_pass http://unix:/run/gunicorn.sock;
}
}
server {
listen 80;
listen [::]:80;
server_name lodugo.com www.lodugo.com;
return 301 https://$server_name$request_uri;
}
我有这样的 gunicorn 服务和套接字:
套接字:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
服务:
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/rienpaAdmin
ExecStart=/var/www/rienpaAdmin/adminPython/bin/gunicorn \
--access-logfile - \
--workers 3 \
--threads 1 \
--bind unix:/run/gunicorn.sock \
rienpaAdmin.wsgi:application
[Install]
WantedBy=multi-user.target
任何人都可以给我一个很好的解释,为什么会这样?我可以升级我的 Linode 服务器,但我真的觉得我当前的一个用户设置应该像第一次请求后一样快速响应,我有几天阅读其他问题,但其中 none 确实帮助我解决了这个问题。
以防万一,我将 Django 3.0 与 postgreSQL 数据库一起使用
编辑:
其中一个答案说我有两个不同 IP 的 A 记录,这是我的 NameCheap 域的 DNS 配置的屏幕截图
你知道你的域名有2条A记录吗?
$ dig lodugo.com
...
;; ANSWER SECTION:
lodugo.com. 1308 IN A 192.64.119.241
lodugo.com. 1308 IN A 45.56.114.74
DNS 服务器将依次响应每个 IP 地址。我怀疑只有一个地址是正确的,所以有 50% 的机会得到一个最终超时的错误地址,然后可能会重试。
这符合我所看到的 - 通常需要很长时间才能连接,但是一旦您输入正确的地址,它就会给出快速响应,直到 DNS 记录到达其 TTL 的末尾。那时你有 50% 的机会再次出现。