Я всегда пытался включить сжатие gzip на веб-серверах, потому что казалось, что у него очень низкая стоимость ЦП и вы получаете значительное сокращение передачи данных.
Теперь у меня есть общедоступный сервер, на котором не включен gzip, и иногда загрузка процессора довольно высока при интенсивном трафике (в основном из-за сложных SQL-запросов на определенных страницах) и чтения эта статья Microsoft Что касается включения, при включении gzip следует учитывать загрузку процессора.
Клиент хочет уменьшить полосу пропускания и ускорить загрузку страницы, но я не уверен, что включение gzip принесет больше вреда, чем пользы, хотя на других серверах он работал хорошо.
По вашему опыту, будет ли сжатие gzip существенно влиять на загрузку процессора?
РЕДАКТИРОВАТЬ: в этом случае мы используем IIS6
Ключевой вопрос - «сколько данных сжимается?».
Если вы выполняете массивный запрос к БД, выполнение которого занимает заметное количество секунд, а результирующая страница занимает несколько десятков килобайт, тогда затраты на сжатие данных будут полностью меньше затрат на работу с SQL для точка, где нет смысла даже думать об этом. Современный процессор практически мгновенно сжимает десятки или сотни Кбайт по сравнению с любым коротким запросом к БД.
Еще один фактор в пользу сжатия заключается в том, что при правильной настройке статические страницы не повторно сжимаются при каждом запросе, а объекты, которые не будут работать (файлы изображений и другие предварительно сжатые), не сжимаются веб-сервером вообще. Для каждого запроса необходимо сжать только динамический контент, который может быть сжимаемым.
Вообще говоря, если у вас нет особой причины не чтобы сжать, рекомендую это сделать. Стоимость ЦП обычно невелика, если вы не запускаете веб-сервер на устройстве с низким энергопотреблением (например, на домашнем маршрутизаторе) по какой-либо причине. Одна из причин, по которой не следует сжимать, - это сценарии, которые используют методы «длинного опроса» для эффективной имитации серверной push-загрузки, или сценарии, которые передают контент в браузер для индикации прогресса - буферизация, подразумеваемая динамическим сжатием, может вызвать тайм-аут таких запросов на клиенте. сторону, но при тщательной настройке вы можете добавить их в список «не сжимать», продолжая сжимать все остальное. Еще одна причина, по которой не следует использовать динамическое сжатие, заключается в том, что это добавляет небольшую задержку к каждому динамическому запросу, хотя для большинства веб-приложений эта разница совершенно незначительна по сравнению с экономией полосы пропускания.
Замечание о загрузке ЦП из-за запросов SQL: это означает, что ваш рабочий набор данных для этих запросов достаточно мал, чтобы поместиться в ОЗУ (в противном случае ваша производительность будет связана с вводом / выводом, а не с ЦП), что является GoodThing ( тм). Высокая загрузка ЦП может быть связана с большим количеством параллельных запросов, как вы подозреваете, но также может быть, что некоторые из них являются объектами сканирования таблиц, которые находятся в выделенной оперативной памяти SQL и / или в кеше ОС (или в противном случае выполняя свою работу долгий путь), поэтому, возможно, стоит регистрировать длительные запросы и проверять, есть ли какие-либо улучшения индексации или другие оптимизации, которые вы можете использовать для сокращения рабочего набора, над которым они работают.
Включение сжатия GZIP не должно существенно повлиять на загрузку вашего процессора. На всякий случай вам также следует проверить потребление памяти, потому что теперь вам нужно будет буферизовать больше данных в памяти перед их отправкой (если только сжатие GZIP не происходит без буферизации обычного текста). Иногда очистка кеша может привести к серьезному замедлению работы веб-сервера.