Есть ли какие-то оговорки с обращением zlib.сжатие выходных данных на моем сервере?


У меня есть zlib и Zend Optimizer включен на моем сервере, и я прочитал о

zlib.output_compression

Директива. Есть ли какие-либо оговорки при включении этой директивы в мой сервер?

4 2

4 ответа:

Сначала вы должны определить, что является узким местом (или, вероятно, будет под нагрузкой).
При включении (прозрачного) сжатия вы обмениваете ресурсы процессора на пропускную способность данных (сети). Итак, вы должны подумать: мои данные (сильно) сжимаемы? Является ли время, необходимое для передачи данных клиенту, узким местом? Сколько ресурсов процессора я могу потратить на сжатие? Какие еще ресурсы использует мой скрипт (например, потребление памяти, подключения к базе данных, ...)? Какой ресурс будет стать узким местом под (тяжелой) нагрузкой? Когда, где и как долго один экземпляр скрипта будет блокировать другой экземпляр? И так далее, и тому подобное.

Вас также могут заинтересовать такие инструменты, как YSlow, профилировщики, встроенные в xdebug, Apache benchmarking tools, (code) caches, такие как apc...и многое другое.

Единственная наиболее эффективная вещь, которую вы можете сделать, чтобы ускорить PHP-код, - это запустить кэшopcode .

Zend Optimizer+ - это один из примеров. Более старый оптимизатор Zend (без"+") был оптимизатором кода, а не кэшем опкодов, и он действительно мог замедлять PHP-код, если вы не использовали кэш опкодов.

После того, как вы сделаете это, то приходит много тяжелой работы, чтобы проверить на наличие узких мест (как уже упоминали другие люди). Вам нужно будет тщательно рефакторинговать код, чтобы смягчить горлышко бутылки. Большинство экспертов по производительности говорят, что проблемы с производительностью вызваны плохой архитектурой приложения, а не отдельными строками кода.

Кэширование содержимого, которое необходимо показать несколько раз, также является распространенным решением для повышения производительности. Но решение о том, какой контент кэшировать и как долго, - это еще одна область, где вам нужно провести тестирование и эксперименты, а также применить суждение.

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

Также часто ваше узкое место может быть в клиенте. Даже если ваш PHP-код быстро запускается на сервере, страница может загружаться неэффективно в браузере, создавая впечатление низкой производительности.

ИМХО, все веб-дизайнеры и разработчики должны сделать книги Стива Соудерса и блоги обязательное чтение.

Это также относится к конфигурации zlib, о которой вы спрашивали, и инструментам измерения производительности клиентов, таким как YSlow и Google PageSpeed.

Изучите профилирование.
Затем оптимизируйте узкие места.

Выходное сжатие - это путь. Установите уровень сжатия равным 1 , так как это дает наибольшее соотношение экономии/загрузки процессора. Уровень по умолчанию равен 6 в масштабе 1-9, что может быть неэффективно, если замедлить процесс на несколько дополнительных байт.