![什么决定了 Nginx 配置中服务器块数量的实际限制?](https://linux22.com/image/639491/%E4%BB%80%E4%B9%88%E5%86%B3%E5%AE%9A%E4%BA%86%20Nginx%20%E9%85%8D%E7%BD%AE%E4%B8%AD%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%9D%97%E6%95%B0%E9%87%8F%E7%9A%84%E5%AE%9E%E9%99%85%E9%99%90%E5%88%B6%EF%BC%9F.png)
我正在尝试弄清楚仅由简单服务器块组成的 Nginx 配置是否可行。每个块都服务于一个子域,并将子域定向到另一个 URL。当然,特定上下文中的最大值取决于参数,因此我更感兴趣的是确定实际限制的因素。
例如,附加服务器块的额外成本(就内存开销而言)是否始终不变?调度到特定服务器块来处理请求的成本是否为常数,还是配置中服务器块数量的函数?
示例服务器块如下:
server {
server_name subdomain.example.com;
return 301 http://some.other.example.org/subdomain;
}
比如说,每个核心每 GB 内存可以有多少个这样的参数,或者其他相关参数?
谢谢。
答案1
影响您可以合理拥有多少个 s 的最大因素server_name
是您的 CPU 的缓存大小(当然还有速度)。
server_name
首先,nginx 将你定义的所有 s 存储到三个哈希表(取决于你是否在名称中使用通配符)每个 nginx 所listen
依赖的 IP/端口对。这些结构的大小被优化为 CPU 缓存行大小的倍数,并且 nginx 旨在能够匹配server_name
传入请求的完全来自CPU缓存而不需要去使用(相对)速度慢得多的 RAM。
nginx 开箱即用地为服务器名称设置了哈希表,其中512 个条目的32 字节每个。它达到 16 KiB,可轻松放入 CPU 的 L1 缓存,或至少放入 L2 缓存。即使您需要扩展它,它仍然应该足够小,大多数时候可以放入缓存中。
此策略建议您应尽量将姓名列表保持在最低限度。
例如,即使匹配通配符条目(如)可能“较慢” .example.com
,但平均而言可能比尝试匹配 example.com 的数百个明确定义的子域更快。
另请参阅 nginx 文档优化server_name
。