是什么决定了Nginx配置中服务器块数量的实际限制？

发布时间：2020-12-13 21:23:15 所属栏目：Nginx 来源：网络整理

导读：我试图弄清楚仅由简单服务器块组成的Nginx配置是否可行.每个块都提供子域,并将子域指向另一个URL.当然,特定环境中的最大值取决于参数,因此我对确定实际限制的因素更感兴趣. 例如,额外服务器块的额外成本(就内存开销而言)总是不变的吗？调度到特定服务器块以

我试图弄清楚仅由简单服务器块组成的Nginx配置是否可行.每个块都提供子域,并将子域指向另一个URL.当然,特定环境中的最大值取决于参数,因此我对确定实际限制的因素更感兴趣.

例如,额外服务器块的额外成本(就内存开销而言)总是不变的吗？调度到特定服务器块以将请求处理为常量的成本是否是配置中服务器块数量的函数？

示例服务器块将是：

server {
    server_name subdomain.example.com;
    return 301 http://some.other.example.org/subdomain;
}

例如,每核心每千兆字节内存或其他相关参数可以有多少？

谢谢.

最佳答案

影响合理数量的server_names的最大因素是CPU的缓存大小(当然还有速度).

首先,nginx将您定义的所有server_names存储到nginx侦听的每个IP /端口对中的三个hash tables(取决于您是否在名称中使用了通配符).这些结构的大小被优化为CPU的缓存行大小的倍数,并且nginx打算能够完全匹配来自CPU缓存的传入请求的server_name,而不必转到(相对)慢得多的RAM. .

开箱即用,nginx为服务器名称设置哈希表,其中512 entries为32 bytes.这达到了16 KiB,很容易适应CPU的L1缓存,或者至少在L2缓存中.即使你需要扩展它,它仍然应该足够小,以适应大多数时间的缓存.

此策略建议您应尽量将名称列表保持在最低限度.

例如,即使匹配诸如.example.com之类的通配符条目可能“慢”,它也可能比尝试与明确定义的example.com的数百个子域匹配更快.

另请参阅optimizing server_names上的nginx文档.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!