Q1: ifmodule mod_php4.c предлагает использовать его для PHP 4, а не для PHP5?
Да. RUN . У PHP4 нет причин оставаться установленным, если у вас нет сценариев, которые будут ломаться под PHP5.
В2: Быстрее ли серверный движок будет иметь это в php.ini вместо htaccess?
Это не должно иметь значения ни на йоту, за исключением нескольких кодов операций при запуске Apache. Это означает, что нет ... если только файл .htaccess еще не был представлен, в этом случае может произойти незначительное снижение производительности, когда Apache найдет файл. (Меньше файлов .htaccess => меньше ненужных stat звонков => более высокая производительность для всего .)
Q3: сжатие по умолчанию установлено на 16386. Что произойдет, если мы снизим его, скажем, до 4K
Это размер буфера для вывода . Если вы уроните его до 4k, данные будут отправлены немного раньше. В зависимости от среднего размера страницы это может означать, что данные могут быть отправлены несколькими порциями, что может очень незначительно снизить производительность пользователя, получающего данные.
Q4: что произойдет, если мы установим его выше, например, 128K?
Это означает, что 128k буферизации будут происходить до того, как данные будут отправлены клиенту. Если после gzip-страниц ваши страницы превышают 128 тыс., Что-то , вероятно, неправильно .
настройка PHP полосы пропускания с экономией и эффективным выигрышем в скорости:
Некоторое время назад люди начали рекомендовать , а не , используя встроенный в PHP gzip, предлагая вместо него Apache mod_deflate . Это позволяет PHP просто заботиться о генерации HTML, а Apache беспокоится о его сжатии и обслуживании. Это также имеет тот же эффект. Хотя страница руководства для mod_deflate является энциклопедической, она также проста и понятна. Возможно, он уже доступен, и в вашем httpd.conf просто отсутствуют необходимые строки.
Поскольку он может работать на уровне «фильтра», его использование также означает, что что угодно , создающее сжатые типы MIME, включая сценарии CGI и простые старые HTML-файлы, может автоматически отправляться в архив.
Обновление с ответами на комментарии:
Правильно ли я прочитал и в промежутках между строками, что вы предлагаете мне убрать блок А, и только * В * в месте, как показано здесь
Как правило, это правильно, хотя имеющийся у вас блок конфигурации в настоящее время нацелен на файлы по расширению. Вместо этого вы можете настроить таргетинг по типу MIME, используя директиву конфигурации AddOutputFilterByType, как описано в руководстве к mod_deflate.
При удалении конфигурации PHP также проверьте php.ini в вашей системе, поскольку он может также содержать директивы сжатия, которые вам могут не понадобиться.
Apache будет достаточно умен, чтобы не дублировать контент, независимо от того, какой метод вы используете для включения mod_deflate.
Как правильно изменить блок A, чтобы сделать его наиболее совместимым с PHP5?
Это зависит от того, как версия 5.x mod_php вызывается в вашей системе. Это будет просто обычный старый mod_php или mod_php5. Найдите директиву LoadModule в другом месте в httpd.conf (или в /etc/httpd/conf.d/*.conf).
Директива фактической конфигурации верна, она просто заключена в блок «делай это только если PHP4 загружен».
Допустим, ваш 5.x mod_php называется mod_not_butter. Если это так, блок будет выглядеть так:
<IfModule mod_not_butter.c>
php_value suckitude_factor -1
</IfModule>
Интересно, какие еще опции я могу настроить / ускорить обработку APZE gzip mod_deflate
Есть много вариантов. Не прикасайтесь к любым из них, кроме размера буфера (DeflateBufferSize), для которого вы должны установить средний несжатый размер данных, который вы ожидаете. (Ранее я ошибочно вспомнил, что буфер был после сжатия, хотя на самом деле он был раньше.)
Все остальные параметры являются нормальными значениями по умолчанию, к которым вам не нужно прикасаться, потому что к тому времени, когда их изменение действительно окажет существенное влияние на производительность, вы захотите задействовать другие технологии, чтобы снять нагрузку с Apache .