OpenResty 的性能优化配置建议

前言

1Panel 的用户越来越多，内置 Web 服务 OpenResty 使用占比也在增加，但网上对其优化的教程很少。博主之前用的是宝塔之前也切换到了1panle了，今天就更新一篇有关 OpenResty 的一些优化建议。可优化设置项较少，需要的小伙伴可以根据实际需求变更配置。如不知道如何迁移网站的可以参考：新手如何将面板从宝塔替换为1panel

1Panel OpenResty 性能优化指南

OpenResty 的优化项大多继承自 Nginx。在 1Panel 的环境中，您通常需要在配置文件 （如 nginx.conf 或相应的虚拟主机配置）中进行调整。

1. 核心 Worker 进程优化 (在 `nginx.conf` 的 `main` 或 `events` 块)

这是决定服务器并发处理能力的最重要配置。

|----------------------|-------------------|----------------------------------------------------------------------------------------------------------------------------------------|
| 设置项 | 建议配置 | 说明与优化点 |
| worker_processes | auto 或 CPU核心数 | 建议设置为 auto，让 Nginx 自动识别 CPU 核心数。一般设置为 CPU 核心数，例如 4 核 CPU 就设置为 4。设置过多反而可能因上下文切换增加开销。 |
| worker_connections | 10240 或更大 | 单个 Worker 进程能打开的最大连接数。计算公式：最大并发连接数 = worker_processes * worker_connections。生产环境建议设置为 10240 或更高，但要确保系统的 文件描述符限制 (ulimit) 足够高。 |
| multi_accept | on | 启用后，Worker 进程可以一次性接受所有新连接，而不是一次只接受一个。在高并发场景下可以提高性能。 |
| use | epoll (Linux) | 适用于 Linux 系统，是高性能 I/O 事件模型。在绝大多数现代 Linux 发行版中，这是默认且最佳的选择。 |

📝 注意： 在 1Panel 中，您需要确保系统级别的 ulimit -n 值大于 worker_connections 的设定值，否则配置无法生效。

2. HTTP 请求与连接优化 (在 `http` 块)

这些设置影响客户端与服务器通信的效率。

|-----------------------------|------------|------------------------------------------------------------------------|
| 设置项 | 建议配置 | 说明与优化点 |
| keepalive_timeout | 65 (秒) | 客户端保持连接的超时时间。过长会浪费资源，过短会增加连接建立开销。65 秒是常用推荐值。 |
| sendfile | on | 允许操作系统直接在内核中发送文件，避免了数据在用户态和内核态之间的拷贝。对于静态文件服务 ，这是必须开启的。 |
| tcp_nopush | on | 结合 sendfile on 使用，在发送响应头和 TCP 缓冲区满后才发送数据。可以有效减少网络包的数量，提高 I/O 效率。 |
| tcp_nodelay | on | 立即发送小数据包，对于 Keepalive 连接非常重要，可以减少响应延迟。建议开启。 |
| client_header_buffer_size | 1k (默认值) | 客户端请求头的缓冲区大小。除非您遇到 HTTP 400 Bad Request 错误，否则保持默认即可。 |

3. 启用 Gzip 压缩

虽然会增加 CPU 负载，但可以极大地减少传输数据量，提升用户体验，尤其是在带宽有限的情况下。

|-------------------|--------------------------------------------------|--------------------------------------------------------------------------|
| 设置项 | 建议配置 | 说明与优化点 |
| gzip | on | 开启 Gzip 压缩。 |
| gzip_comp_level | 5 或 6 | 压缩级别。1 最快，9 压缩率最高。通常 5 或 6 能在 CPU 消耗和压缩率之间取得良好平衡。 |
| gzip_min_length | 1024 | 仅压缩大于此字节数的文件。避免对小文件进行压缩，因为压缩带来的 CPU 开销可能大于传输节省的效益。 |
| gzip_types | text/plain application/javascript text/css ... | 指定需要压缩的文件 MIME 类型。不要压缩图片、视频等已压缩格式 （如 .jpg, .png, .zip），浪费 CPU。 |

4. OpenResty LuaJIT 相关优化 (在 `http` 块)

OpenResty 核心的性能优势在于 LuaJIT。确保启用 Lua 代码缓存是至关重要的。

|-------------------|-------------|-----------------------------------------------------------------------------------------------|
| 设置项 | 建议配置 | 说明与优化点 |
| lua_code_cache | on (生产环境) | 生产环境必须开启 。开启后，LuaJIT 才会对 Lua 代码进行编译和 JIT 优化，带来巨大的性能提升。调试时才设置为 off。 |
| lua_shared_dict | 根据需求配置 | 如果您的 Lua 代码使用了共享内存（用于缓存、限流等），必须配置此项。例如：lua_shared_dict cache_dict 100m;。合理分配大小，避免浪费或不足。 |

5. 日志优化

在高并发场景下，频繁的磁盘 I/O 写日志会成为瓶颈。

|--------------|---------------|-----------------------------------------------------------------------------------------------------------|
| 设置项 | 建议配置 | 说明与优化点 |
| access_log | 根据需求，可关闭或使用缓存 | 如果访问量极大且不需要详细日志：access_log off;。如果需要：可以考虑将日志写入 Ring Buffer 或使用 buffer 和 flush 参数，减少 I/O 频率。 |

`6：server_names_hash_bucket_size` 参数优化

|--------------|---------------------------------|-------------------------------------------------------------------|
| 类别 | 参数名 | 含义 |
| Nginx 核心 | server_names_hash_bucket_size | 服务器域名 Hash 表桶大小 。用于存储虚拟主机 (Virtual Host) 的域名 (server_name)。 |

核心原理与意义

哈希表 (Hash Table)： Nginx 使用哈希表来快速查找客户端请求的 Host 头属于哪个 server 块。server_names_hash_bucket_size 定义了这个哈希表每个桶 (Bucket) 的最大字节数。
触发错误： 如果您配置的 域名过长 或 域名数量过多 导致 Nginx 在初始化时无法将所有域名放入哈希表桶中，Nginx 会启动失败并报错：

could not build server_names_hash, you should increase server_names_hash_bucket_size
优化目标： 调整此参数的目的是为了避免哈希冲突 和确保所有域名能被成功加载，同时尽可能地减少查找时间。

优化建议

默认值： 默认值通常为 32 或 64 字节（取决于 CPU 缓存行大小）。

|-------------|------------------------------------------------------|-------------------------------------------------------------------------------|
| 优化场景 | 建议值 | 理由 |
| 标准/一般配置 | 64 | 通常情况下，默认值或略微增加到 64 字节即可满足需求。 |
| 域名较多或较长 | 128 或 256 | 当服务域名数量较多，或使用了很长的泛域名 （如 *.subdomain.longdomainname.com）时，需增大此值以容纳最长的键值。 |
| 高性能服务器 | 256 | 如果服务器配置很高，直接设置为 256 字节是一个安全且能确保快速加载的保守值，能有效避免未来的配置问题。 |
| 经验法则 | \frac\text{server\_names\_hash\_max\_size2 | 建议将其设置为 server_names_hash_max_size 参数值的 \frac1\2到 \frac1\3左右，两者需要协调工作。 |

配置位置

该参数通常配置在 Nginx 配置文件的 http块中：

Nginx

复制代码

http {
    # 建议在此处进行配置
    server_names_hash_bucket_size 128; 
    # server_names_hash_max_size 512; # 另一个相关参数
    ...
}

重点提示：

增大此值会轻微增加内存使用，但能显著提高域名查找的稳定性和初始化成功率。在 1Panel 的环境中，如果您的 Web 服务数量较多，建议将其设置为 128 或 256。

`7：client_header_buffer_size` 参数优化

|----------------|-----------------------------|---------------------|
| 类别 | 参数名 | 含义 |
| Nginx HTTP | client_header_buffer_size | 读取客户端请求头的缓冲区大小。 |

核心原理与意义

功能： 该参数定义了 Nginx 用于存储客户端请求行 （如 GET /path HTTP/1.1）和请求头 （如 Host, User-Agent, Cookie 等）的内存大小。
默认值： 默认值通常为1K字节（即 1024 字节）。
触发错误： 如果客户端发送的请求头（尤其是 Cookie 字段或包含大量自定义头的请求）的总大小超过此限制，Nginx 无法完整读取请求头，会立即返回 HTTP 400 Bad Request 错误给客户端。

优化建议

默认值： $1\\text{k}$

|-----------------------|-------------|-----------------------------------------------------------------------|
| 优化场景 | 建议值 | 理由 |
| 标准/常规服务 | 保持默认 1K | 对于大多数标准网站和 API，请求头通常较小，默认值足够。 |
| 大型 Cookies/SSO 场景 | 4K或8K | Cookie 字段是导致请求头增大的最常见原因，特别是在使用了复杂的身份验证系统 (SSO/OAuth) 或有大量会话数据的应用中。 |
| 业务需求特殊 | 16K或32K | 极少数情况下，如果业务逻辑要求传递非常大的自定义头，或需要处理非常庞大的 Cookies，可以适当增大。32K是一个较高的上限值。 |

注意事项

内存消耗： 这个缓冲区是针对每个连接分配的。如果设置得太大（例如 32K）并且并发连接数很高（例如 10,000 个连接），会显著增加 Nginx 的内存消耗（10,000 \times 32K\approx 320\MB）。
配置位置： 该参数配置在 Nginx 配置文件的 http块中。

建议： 从小处开始调整。 优先将缓冲区大小从 1K 增加到4K 或8K。只有在确认 8k 仍然出现 400 错误时，才考虑进一步增加到16K 或32K。

`8：client_max_body_size` 参数优化

|----------------|------------------------|---------------------------------------|
| 类别 | 参数名 | 含义 |
| Nginx HTTP | client_max_body_size | 限制客户端请求主体 (Request Body) 的最大允许大小。 |

核心原理与意义

功能： 此参数控制了 Nginx 接受的 HTTP 请求中 POST或 PUT等请求方法携带的数据体 （如表单数据、文件内容、JSON/XML负载等）的上限。
默认值： 默认值通常为 1M(1 兆字节)。
触发错误： 如果客户端发送的数据体大小超过此限制，Nginx 会立即返回 HTTP 413 Request Entity Too Large 错误给客户端，并在日志中记录相关信息。
重要性： 设置合理的限制是重要的安全措施 ，可以防止拒绝服务 (DoS) 攻击------通过发送超大请求来耗尽服务器的内存和带宽资源。

优化建议

**默认值：**1M

|---------------|----------------|---------------------------------------------------------------------------|
| 业务场景 | 建议值 | 理由 |
| 通用 Web 表单 | 1M- 10M | 对于普通的登录、搜索、配置提交等请求，默认值 1M 或 5M通常足够。如果包含少量图片上传，可提高到 10M。 |
| 大文件上传服务 | 50M - 512M | 对于图片、视频、文档等文件的上传服务，需要根据业务允许的最大文件大小来设置。例如，允许用户上传最大 100M的视频，则应设置为 100M 或略高。 |
| API 服务 | 1M-10M | 对于 JSON/XML API，数据负载通常较小。除非业务需要传递大型数据对象，否则 1M - 10M 足够，并能提供较好的安全防护。 |

注意事项与配置

单位： 可以使用 k(千字节)、m (兆字节) 或 g (吉字节) 作为单位。
内存消耗： 这个参数不会直接大幅增加 Nginx 的内存消耗，因为 Nginx 通常会将请求体写入临时文件，而不是完全加载到内存中。但过大的值会增加磁盘 I/O 和处理时间。
配置位置： 该参数可以在 Nginx 配置文件的 http块、server块或 location块中配置。
- 在 location 块配置时，可以为不同的路径提供不同的限制，例如：
  复制代码
```
http {
    client_max_body_size 10m; # 默认值

    server {
        location /upload/videos {
            client_max_body_size 512m; # 针对特定上传路径放宽限制
        }
    }
}
```
代理链： 如果 OpenResty 前面还有负载均衡器或 CDN (如 Varnish, Cloudflare)，也需要确保整个代理链路上所有设备的请求主体限制都大于或等于此值，否则客户端仍可能被上游设备拒绝。

`9：keepalive_timeout` 参数优化

|----------------|---------------------|-------------------------------|
| 类别 | 参数名 | 含义 |
| Nginx HTTP | keepalive_timeout | 设置长连接 (Keep-Alive) 的超时时间。 |

核心原理与意义

功能： 此参数定义了客户端与服务器建立连接后，在没有数据传输时 ，连接可以保持空闲的最大秒数。
HTTP/1.1 与 Keep-Alive： HTTP/1.1 默认启用 Keep-Alive (持久连接)。它允许在同一 TCP 连接 上发送和接收多个 HTTP 请求/响应，而不是每发送一个请求就建立和断开一次连接。
重要性：
- 提高效率： 避免了频繁建立和断开 TCP 连接（三次握手/四次挥手）的延迟和开销。
- 性能提升： 对于加载多个资源的网页（如图片、CSS、JS），可以在一个连接上快速完成加载，显著减少延迟。
超时后果： 一旦连接空闲时间超过 keepalive_timeout，Nginx 会主动关闭该 TCP 连接。

优化建议

推荐范围： 60 秒到 90 秒。

|-----------------|-----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
| 优化场景 | 建议值 | 理由 |
| 标准 Web 服务 | 65 秒 | 这是一个行业通用且推荐的值。它足够长，能保证客户端在加载页面资源时不会断开连接，同时又不会长时间占用服务器资源。 |
| 负载均衡器/CDN 后 | 需与上游匹配 | 如果您的 OpenResty 服务器位于 负载均衡器 (LB) 或 CDN 之后，keepalive_timeout 必须小于或等于上游设备（如阿里云 SLB、Cloudflare 等）设定的超时时间。否则，LB 会先断开连接，导致 Nginx 出现不必要的错误或资源浪费。 |
| 移动端/高并发 | 30 秒 - 60 秒 | 在移动网络不稳定或服务器并发连接数极高的场景，可以适当缩短，以便更快释放空闲连接，为新连接腾出资源。 |

注意事项与配置

资源占用： 时间过长 （300S）会导致 Nginx 的 Worker 进程 持有大量空闲连接，消耗内存和文件描述符，在高并发下可能导致资源耗尽。
时间过短： 时间过短 （如 10S）会迫使客户端频繁重新建立连接，反而增加了延迟和 TCP/IP 握手开销。

配置位置： 该参数通常配置在 Nginx 配置文件的 http块中：

http {
keepalive_timeout 65; # 推荐值

复制代码

  # 另一个相关参数：限制单个连接上允许的最大请求数
  keepalive_requests 100; # 默认值，不宜过大
  ...

}

结论： 将 keepalive_timeout 保持在 60-75 秒的范围内，是平衡性能提升和资源占用的最佳实践。

优化后的配置示例

复制代码

http {
    # gzip相关配置
    gzip on;
    gzip_min_length 1k;
    gzip_comp_level 6;
    gzip_buffers 4 16k;
    gzip_http_version 1.1;
    gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php application/json;
    gzip_vary on;
    gzip_proxied any;
    gzip_disable "msie6";

    # 服务器名字hash表大小
    server_names_hash_bucket_size 128;

    # 客户端请求头缓冲区大小
    client_header_buffer_size 32k;
    large_client_header_buffers 4 32k;

    # 客户端请求主体最大允许大小
    client_max_body_size 32m;

    # 长连接超时时间
    keepalive_timeout 60;

    # 其他配置...
}

总结

以上就是今天分享的全部内容了，都是基于VMRack 三网精品 4核4G的机器捣鼓出来的。你可以根据网站的负载类型 （静态服务多还是动态计算多）和资源配置（CPU 核心数、内存大小）来调整上述配置，并在实际环境中进行压力测试以找到最佳平衡点。

本文原发于我的博客：landonVPS

OpenResty 的性能优化配置建议

前言

1Panel OpenResty 性能优化指南

1. 核心 Worker 进程优化 (在 nginx.conf 的 main 或 events 块)

2. HTTP 请求与连接优化 (在 http 块)

3. 启用 Gzip 压缩

4. OpenResty LuaJIT 相关优化 (在 http 块)

5. 日志优化

6：server_names_hash_bucket_size 参数优化

核心原理与意义

优化建议

配置位置

7：client_header_buffer_size 参数优化

核心原理与意义

优化建议

注意事项

8：client_max_body_size 参数优化

核心原理与意义

优化建议

注意事项与配置

9：keepalive_timeout 参数优化

核心原理与意义

优化建议

注意事项与配置

优化后的配置示例

总结

1. 核心 Worker 进程优化 (在 `nginx.conf` 的 `main` 或 `events` 块)

2. HTTP 请求与连接优化 (在 `http` 块)

4. OpenResty LuaJIT 相关优化 (在 `http` 块)

`6：server_names_hash_bucket_size` 参数优化

`7：client_header_buffer_size` 参数优化

`8：client_max_body_size` 参数优化

`9：keepalive_timeout` 参数优化