Сжатие содержимого с помощью PHP ob_start () против Apache Deflate / Gzip? - PullRequest
Новая
       34

Сжатие содержимого с помощью PHP ob_start () против Apache Deflate / Gzip?

25 голосов
/ 07 декабря 2009

Большинство сайтов хотят сжать свой контент, чтобы сэкономить на пропускной способности. Однако, когда дело доходит до серверов Apache, работающих на PHP, есть два способа сделать это - с PHP или с Apache. Так какой из них быстрее или проще на вашем сервере?

Например, в PHP я запускаю следующую функцию в начале своих страниц, чтобы включить ее: 

/**
 * Gzip compress page output
 * Original function came from wordpress.org
 */
function gzip_compression() {

    //If no encoding was given - then it must not be able to accept gzip pages
    if( empty($_SERVER['HTTP_ACCEPT_ENCODING']) ) { return false; }

    //If zlib is not ALREADY compressing the page - and ob_gzhandler is set
    if (( ini_get('zlib.output_compression') == 'On'
        OR ini_get('zlib.output_compression_level') > 0 )
        OR ini_get('output_handler') == 'ob_gzhandler' ) {
        return false;
    }

    //Else if zlib is loaded start the compression.
    if ( extension_loaded( 'zlib' ) AND (strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== FALSE) ) {
        ob_start('ob_gzhandler');
    }

}

Другой вариант - использовать Apache deflate или gzip (оба очень близки ). Чтобы включить их, вы можете добавить что-то подобное в ваш файл .htaccess. 

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/x-httpd-php

Поскольку PHP является языком сценариев (который должен загружаться PHP), я бы предположил, что метод apache будет 1) более стабильным и 2) более быстрым. Но предположения не имеют большого смысла в реальном мире.

В конце концов, вы бы предположили, что с огромными финансовыми окнами поддержки ... э-э , мы туда не пойдем.

1 Ответ

14 голосов
/ 08 декабря 2009

Мы работаем ... много веб-серверов, обрабатывающих 60M / уникальных / день. Обычно это не стоит упоминать, но ваш вопрос кажется основанным на опыте.

Мы работаем с этим в Apache. То, что выходит на другом конце, одинаково (или достаточно близко, чтобы не иметь значения) независимо от выбранного вами метода.

Мы выбираем apache по нескольким причинам:

  • Нулевое обслуживание, мы просто включили его. Никто не должен поддерживать некоторую структуру дел
  • Производительность, в наших тестовых серверах, где Apache выполнял работу, работала незначительно лучше.
  • Apache будет применять фильтр вывода ко всему, а не только к PHP. В некоторых случаях на том же сервере обслуживаются другие типы контента, мы хотели бы сжать наши .css и .js

Одно предупреждение: некоторые браузеры или другие приложения целенаправленно манипулируют заголовками клиентов, указывая на то, что сжатие поддерживается. Некоторые делают это, чтобы облегчить свою работу с точки зрения безопасности на стороне клиента (например, такие приложения, как Norton Internet Security и т. Д.). Вы можете либо игнорировать это, либо попытаться добавить дополнительные случаи, чтобы переписать запросы, чтобы они выглядели нормально (браузеры действительно поддерживают это, приложение или прокси просто отключили его, чтобы упростить свою жизнь).

В качестве альтернативы, если вы используете команду flush () для более ранней отправки вывода в браузер и применяете сжатие, вам может потребоваться заполнить конец строки пробелами, чтобы убедить сервер отправить данные раньше.

...