Foreword

As the user base of 1Panel continues to grow, so does the usage of its built-in web service, OpenResty. However, there are few tutorials available online on how to optimize it. I, the blogger, previously used BT Panel and have also switched to 1Panel, so today I'm sharing some optimization tips for OpenResty. There are limited configurable settings for optimization, so feel free to adjust the configurations based on your actual needs. If you are unsure how to migrate your website, please refer to: [How a Novice Can Replace BT Panel with 1Panel].

1Panel OpenResty Performance Optimization Guide

Most of OpenResty's optimization settings are inherited from Nginx. In the 1Panel environment, you typically need to make adjustments in the configuration files (such as nginx.conf or the corresponding virtual host configuration).

1. Core Worker Process Optimization (in nginx.conf's main or events block)

This is the most critical configuration for determining the server's concurrent processing capability.

Note: In 1Panel, you must ensure that the system-level ulimit -n value is greater than the set value of worker_connections, otherwise the configuration will not take effect.

2. HTTP Request and Connection Optimization (in the http block)

These settings affect the efficiency of client-server communication.

3. Enabling Gzip Compression

Although it increases CPU load, it greatly reduces the amount of data transferred, improving user experience, especially in environments with limited bandwidth.

4. OpenResty LuaJIT Optimization (in the http block)

OpenResty's core performance advantage lies in LuaJIT. Ensuring that Lua code caching is enabled is vital.

5. Log Optimization

In high-concurrency scenarios, frequent disk I/O for writing logs can become a bottleneck.

6. server_names_hash_bucket_size Parameter Optimization

Core Principle and Significance

• Hash Table: Nginx uses a hash table to quickly determine which server block corresponds to the client's Host header. server_names_hash_bucket_size defines the maximum byte size for each bucket in this hash table.

• Error Trigger: If your configured domain name is too long or you have too many domain names, Nginx may fail to load all domains into the hash table buckets during initialization, leading to an error: could not build server_names_hash, you should increase server_names_hash_bucket_size.

• Optimization Goal: To avoid hash collisions and ensure all domain names are successfully loaded, while minimizing lookup time.

Optimization Recommendations

Configuration Location: Typically in the Nginx configuration file's http block:

Nginx

http {
    # Recommended to configure here
    server_names_hash_bucket_size 128; 
    # server_names_hash_max_size 512; # Another related parameter
    ...
}

Key Takeaway: Increasing this value slightly increases memory usage but significantly improves domain lookup stability and initialization success rate. For many web services in the 1Panel environment, $128$ or $256$ is recommended.

7. client_header_buffer_size Parameter Optimization

Core Principle and Significance

• Function: Defines the memory size Nginx allocates to store the client request line (e.g., GET /path HTTP/1.1) and request headers (e.g., Host, User-Agent, Cookie).

• Default Value: Usually $1\text{k}$ byte (i.e., 1024 bytes).

• Error Trigger: If the total size of client request headers (especially the Cookie field or requests with numerous custom headers) exceeds this limit, Nginx cannot read the header completely and immediately returns an HTTP 400 Bad Request error.

Optimization Recommendations

Suggestion: Adjust incrementally. Prioritize increasing the buffer size from $1\text{k}$ to $4\text{k}$ or $8\text{k}$. Only consider increasing to $16\text{k}$ or $32\text{k}$ if $8\text{k}$ still results in 400 errors.

8. client_max_body_size Parameter Optimization

Core Principle and Significance

• Function: Controls the upper limit of the data body carried by HTTP requests (like POST or PUT), such as form data, file content, or JSON/XML payloads.

• Default Value: Typically $1\text{m}$ (1 Megabyte).

• Error Trigger: If the client's request body size exceeds this limit, Nginx immediately returns an HTTP 413 Request Entity Too Large error.

• Importance: Setting a reasonable limit is a crucial security measure to prevent Denial of Service (DoS) attacks by exhausting server resources with oversized requests.

Optimization Recommendations

Configuration Location: Can be set in the http, server, or location block.

Nginx

http {
    client_max_body_size 10m; # Default value
    
    server {
        location /upload/videos {
            client_max_body_size 512m; # Relax limit for specific upload path
        }
    }
}

Proxy Chain: If OpenResty is behind a load balancer or CDN, ensure that all devices in the proxy chain have a request body limit greater than or equal to this value.

9. keepalive_timeout Parameter Optimization

Core Principle and Significance

• Function: Defines the maximum seconds a connection can remain idle after being established between the client and server.

• Keep-Alive: Allows multiple HTTP requests/responses to be sent over the same TCP connection, avoiding the overhead of frequent connection establishment/teardown.

• Importance: Improves efficiency and reduces latency for loading web pages with multiple resources.

• Timeout Consequence: Nginx closes the TCP connection when the idle time exceeds keepalive_timeout.

Optimization Recommendations

Configuration Location: Typically in the Nginx configuration file's http block.

Nginx

http {
    keepalive_timeout 60; # Recommended value
    # keepalive_requests 100; # Another related parameter
    ...
}

Conclusion: Keeping keepalive_timeout in the $60$ - $75$ second range is the best practice for balancing performance improvement and resource utilization.

Optimized Configuration Example

Nginx

http {
    # Gzip Configuration
    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";

    # Server Name Hash Table Size
    server_names_hash_bucket_size 128;

    # Client Header Buffer Size
    client_header_buffer_size 32k;
    large_client_header_buffers 4 32k;

    # Client Request Body Max Size
    client_max_body_size 32m;

    # Keep-Alive Timeout
    keepalive_timeout 60;

    # Other configurations...
}

Conclusion

That concludes today's sharing, which was based on tinkering with a VMRack Premium Triple-Network 4-Core 4G machine. You can adjust these settings based on your website's load type (more static serving or dynamic computing) and resource configuration (CPU cores, memory size), and perform stress testing in your actual environment to find the optimal balance.