我有一个网站,其中的所有页面均由 nginx 的 http 缓存提供,并且很少失效或过期。
平均总页面下载大小约为 2 MB,但尽管这是一个没有任何有趣逻辑的静态网站,我的服务器响应时间约为一秒
我记录了 nginx 的时间$request_time
,从服务器算起大约需要 400 毫秒
每个文件平均大小为 20-30 KB
400毫秒似乎有些荒谬。
我落后了Cloudflare和
sendfile on;
tcp_nopush off;
tcp_nodelay on;
keepalive_timeout 300s;
keepalive_requests 10000;
我应该怎么做才能将响应时间缩短到 150 毫秒范围?
编辑:我调整的第一部分。
意识到我没有打开 SSL OSCP。调整代码以
# https://github.com/autopilotpattern/wordpress/issues/19
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_certificate /etc/letsencrypt/live/site.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/site.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/site.com/chain.pem;
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
ssl_stapling on;
ssl_stapling_verify on;
我将汇报改进情况。
编辑2:
以下是从印度到美国西海岸服务器的 3G 连接网页测试结果
答案1
您的设置从根本上来说存在很多错误。
首先,你根本不需要 NGINX。Cloudflare 中已经有缓存系统了,就用它吧。这个系统比你的 NGINX 更接近用户。
其次,您说“3G 连接很慢”——就是这样。印度的固定电话很差(印度 -> 美国... 从网吧测量那里的纯 ping 延迟)。3g 非常老旧且缓慢。延迟为 100 到 500mshttps://hpbn.co/mobile-networks/
您将以下条件添加到基准中:“平均总页面下载大小约为 2 MB”和“每个文件平均大小为 20-30 KB”,这样就得到了结果。浏览器不会同时发出太多请求,这意味着您会在高延迟链接上传输大量文件。
你可以:
- 减小尺寸,但至少
- 减少文件数量,从而减少握手。
但不要期望太多。请注意,根据您的测量,您在 DNS 查找上花费了近 500 毫秒,在连接的初始设置上花费了近 500 毫秒,在 SSL 握手上(在您和 Cloudflare 服务器之间)又花费了大约 600 毫秒 - 这是高延迟连接设置的代价。没有什么可以解决这个问题。那是 1.5 秒,因为我想说大部分是 3g。
Cloudflare 本身就是缓存,除非您的 Web 服务器上的设置很糟糕 - 这意味着您的所有优化都是无用的,因为您的服务器应该很少受到攻击。而且,3g 速度太慢了。您认为为什么我们现在使用 5g?
你最好在 stackoverflow 上重新问这个问题 - 如何优化网站代码以更适合低延迟连接。比如减少文件数量。否则就只能忍受“旧技术不是最优的”。
答案2
我认为你还没有搞清楚优化问题。首先你需要弄清楚时间都花在哪儿了。
我认为您说的不是浏览器中的显示时间,因此暂时不要使用浏览器。使用轻量级命令行工具(如 curl 和 ab)来收集您的时间信息。从您的桌面或除为本网站提供服务的服务器之外的连接良好的服务器使用此类工具可能会有所帮助,以排除本地系统、网络或浏览器的问题。
使用 ab(apache 工具附带)或 curl 在您的服务器上运行一些测试,这样您就可以消除网络延迟和 cloudflare 的影响。您需要使用选项来连接到您的本地 http 服务器,而不是 DNS 指向的位置,并使用正确的Host
标头。您的延迟现在看起来如何?这应该会告诉您问题是在您的 Web 服务器中还是在其外部。它包括您的 nginx 缓存的优势,但不包括来自 cloudflare 的任何缓存。
如果您的服务器上的这个位很快,那么您正在查看 cloudflare 和网络。否则,请继续查看您的服务器。
除了从客户端的角度查看请求所用的时间之外,您还可以修改 nginx 日志格式,以在日志中获取更多时间信息。我通常使用类似以下内容:
log_format combined '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$request_time" "$msec"';
如果情况允许,我会在我使用的大多数服务器上永久保留此日志记录设置。
如果您仍然看到$request_time
日志中字段记录的延迟,那么top
或atop
或类似命令可能会帮助您确定时间是在 nginx 内花费还是在等待其他进程。
当您弄清楚哪种进程有延迟时,您很可能能够使用 来弄清楚发生了什么strace
。 ltrace
有时同样有用,有时需要使用调试器转到完整的配置文件或带有时间信息的跟踪,尽管这通常是一种相当耗时的方法。绝对从 开始strace
。
我预计您还会有更多问题,但您不必关注所有可能引起关注的领域的细节,不妨尝试上述方法,然后再就您发现的问题添加更多细节?