Сжатие Http gzip и производительность

Ключевой вопрос, "сколько данных сжимается?".

При выполнении значительного запроса DB, который берет значимое число секунд для выполнения, и получающаяся страница является несколькими десятками Кбита долго, то расход сжатия данных полностью затмится расходом работы SQL до такой степени, когда нет никакого смысла даже думающего об этом. Современный ЦП собирается сжать десятки или сотни Кбита в значительной степени немедленно по сравнению с любым коротким запросом DB.

Другой фактор в пользу сжатия - то, что, правильно настроенные, статические страницы не повторно сжаты по каждому запросу и объектам, которые не извлекут выгоду (файлы изображений и другие, которые предварительно сжаты), не сжаты веб-сервером вообще. Только динамичный likely-to-be-compressible довольный потребность быть gzipped по каждому запросу.

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

Примечание стороны по загрузке ЦП из-за SQL-запросов: это подразумевает, что Ваш рабочий набор данных для этих запросов является достаточно небольшим для помещений в RAM (иначе производительностью был бы ввод-вывод, связанный а не зависящий от ЦП), который является GoodThing (TM). Высокая загрузка ЦП могла просто произойти из-за количества сдвига параллельных запросов, как Вы подозреваете, но могло также случиться так, что некоторые из них являются сканирующими таблицу объектами, которые находятся в выделенной RAM SQL и/или кэше ОС (или они иначе делают свою работу длинный путь вокруг), таким образом, могло бы стоить зарегистрировать длительные запросы и проверить, чтобы видеть, существуют ли какие-либо улучшения индексации или другие оптимизации, которые можно использовать для сокращения рабочего набора, которым они управляют.