Mức gzip nén nginx tốt nhất là gì?

Tôi đang sử dụng bộ đệm proxy ngược nginx với kích hoạt gzip. Tuy nhiên, tôi đã gặp một số vấn đề từ các ứng dụng Android yêu cầu HTTP đến dịch vụ web Rails JSON của tôi. Có vẻ như khi tôi tắt bộ đệm proxy ngược, nó hoạt động tốt vì tiêu đề phản hồi không có gzip. Do đó, tôi nghĩ vấn đề là do gzip. Mức độ nén gzip thích hợp nhất là gì?

gzip               on;
gzip_http_version  1.0;
gzip_vary          on;
gzip_comp_level    6;
gzip_proxied       any;
gzip_types         text/plain text/css text/javascript application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss;

Mức độ nén gzip chỉ đơn giản xác định mức độ nén của dữ liệu theo thang điểm từ 1-9, trong đó 9 là mức nén nhiều nhất. Sự đánh đổi là dữ liệu được nén nhiều nhất thường đòi hỏi nhiều công việc nhất để nén / giải nén, vì vậy nếu bạn đặt nó ở mức khá cao trên một trang web có khối lượng lớn, bạn có thể cảm thấy hiệu quả của nó.

Có vẻ như các vấn đề của bạn liên quan nhiều hơn đến các tiêu đề HTTP trên các yêu cầu. Thông thường lưu lượng HTTP được nén bằng gzip được kèm theo Content-Encoding: gziptiêu đề. Nếu điều này bị bỏ ở đâu đó, thì khách hàng có thể không biết phải giải nén phản hồi.

Tôi đã thử nghiệm điều này theo nginx 1.3.9 với hai tệp và đây là những kết quả tôi nhận được cho các cấp độ khác nhau:

text/html - phpinfo ():

0    55.38 KiB (100.00% of original size)
1    11.22 KiB ( 20.26% of original size)
2    10.89 KiB ( 19.66% of original size)
3    10.60 KiB ( 19.14% of original size)
4    10.17 KiB ( 18.36% of original size)
5     9.79 KiB ( 17.68% of original size)
6     9.62 KiB ( 17.37% of original size)
7     9.50 KiB ( 17.15% of original size)
8     9.45 KiB ( 17.06% of original size)
9     9.44 KiB ( 17.05% of original size)

application/x-javascript - jQuery 1.8.3 (Không nén):

0    261.46 KiB (100.00% of original size)
1     95.01 KiB ( 36.34% of original size)
2     90.60 KiB ( 34.65% of original size)
3     87.16 KiB ( 33.36% of original size)
4     81.89 KiB ( 31.32% of original size)
5     79.33 KiB ( 30.34% of original size)
6     78.04 KiB ( 29.85% of original size)
7     77.85 KiB ( 29.78% of original size)
8     77.74 KiB ( 29.73% of original size)
9     77.75 KiB ( 29.74% of original size)

Tôi không chắc đây là đại diện như thế nào nhưng nó sẽ là một ví dụ. Ngoài ra, tôi chưa tính đến việc sử dụng CPU nhưng từ những kết quả này, mức độ nén lý tưởng dường như nằm giữa 4và 6.

Ngoài ra, nếu bạn sử dụng gzip_staticmô-đun, bạn có thể muốn nén trước các tệp của mình (bằng PHP):

function gzip_static($path)
{
    if ((extension_loaded('zlib') === true) && (is_file($path) === true))
    {
        $levels = array();
        $content = file_get_contents($path);

        foreach (range(1, 9) as $level)
        {
            $levels[$level] = strlen(gzencode($content, $level));
        }

        if ((count($levels = array_filter($levels)) > 0) && (min($levels) < strlen($content)))
        {
            if (file_put_contents($path . '.gz', gzencode($content, array_search(min($levels), $levels)), LOCK_EX) !== false)
            {
                return touch($path . '.gz', filemtime($path), fileatime($path));
            }
        }
    }

    return false;
}

Điều này cho phép bạn có được khả năng nén tốt nhất có thể mà không phải hy sinh CPU theo mọi yêu cầu.

Nếu bạn thực sự có thể dự phòng tài nguyên CPU, bạn có thể sử dụng 9, nhưng đối với hầu hết các trang web, giá trị 2 là đủ, vì gzip không làm giảm tệp nhiều sau cấp 1.

Chỉnh sửa: Tôi đã xem Amazon CloudFront và có vẻ như nó đang sử dụng cấp 6, có lẽ vì cấp độ đó là cấp độ giải nén nhanh hơn, do đó cải thiện hiệu suất hiển thị trang.

Nếu bạn có trang web có khối lượng lớn và vẫn muốn có mức nén (9) đầy đủ, ý tưởng tốt nhất là đưa nội dung tĩnh của bạn lên Amazon S3 hoặc các dịch vụ lưu trữ đối tượng tương tự và tải lên các tệp nén.

Bạn vẫn muốn sử dụng nginx để nén HTML của mình, vì vậy tốt hơn để giữ giá trị đó ở mức bình thường, tôi sử dụng 5 ở đó.