Флаг в руки. Я обеими руками за. А майкрософту надо оторвать кой-чего за то, что IE6 GZIP'у не обучен. Имейте ввиду и проверяйте заголовки, я выше писал как.
Ничего оно не ухудшит. Почитайте википедию — там доступно разъяснено, что нужен он когда надо переслать 1 байт, а заголовков при этом на 40. Это довольно расточительно, поэтому пакет собирается по кускам и отправляется за один заход.
Ну я как-то больше привык сам настраивать :) потому что хрен его знает что там админы намутили… Кстати есть какие-то хорошие хостеры на примете? (лучше в личку наверно)
Я имел ввиду, что надо отдавать в самом конце, после всей логики. Чтобы после тяжелого принта не было выполнения. Т.к. пока принт не выполнится, до того, что за ним дело не дойдет. Нам то важно, чтобы скрипт быстро отработал и отдал данные — тогда перед принтом можно и соединения позакрывать и память почистить.
Подумал еще разок — может тот скрипт, что отдает GZIP просто не ставит соответствующие заголовки Content-Encoding: gzip? Это тупо конечно, но другой причины я реально не вижу, по крайней мере с серверной стороны.
Чтобы сайт был стоек к DDoS вероятно лучше пользоваться FastCGI, но только не с PHP, а допустим с Perl. Потому что перл песочницу создает однократно и надо только будет следить, чтоб не было утечек памяти, а РНР будет все равно запускаться каждый раз с нуля.
В большинстве сайтов, которые мне довелось видеть, всяческие autoexec и фреймворки грузятся зачастую дольше, чем сам скрипт работает ;). Поэтому если каждый раз экономить по 50-100 мс на подготовке, то за 100 запросов мы получим нехилую экономию. Даже при учете, что допустим сам скрипт работает еще столько же.
А насчет TIDY я еще не думал честно говоря… Кстати есть мнение, что нужно не только JS, но и CSS и HTML отдавать в «minified» виде. Не удобно при разработке, зато после публикования можно смело врубать.
GZIP об IE6 споткнётся, а так у меня на сайтах так и делается — сначала все в буфер, потом если есть возможность — в GZIP или DEFLATE, в результате имеем
Сжатие DEFLATE: 8.84 КБ → 2.78 КБ (68,6%)
Полное время выполнения: 0,051 сек.
А у нас наоборот пакет здоровый.
Display Length: 1304 KiB.
Reach end file: 1.03 ms.
if(isset($_SERVER['HTTP_ACCEPT_ENCODING'])) $acceptEnc = $_SERVER['HTTP_ACCEPT_ENCODING']; else $acceptEnc = $_SERVER['HTTP_TE'];
$_SERVER[cmsGZIP] = array(
«enabled» => (stristr($acceptEnc, 'gzip') || stristr($acceptEnc, 'deflate'))? true: false,
«algorythm» => (stristr($acceptEnc, 'deflate'))? «deflate»: «gzip»,
);
В большинстве сайтов, которые мне довелось видеть, всяческие autoexec и фреймворки грузятся зачастую дольше, чем сам скрипт работает ;). Поэтому если каждый раз экономить по 50-100 мс на подготовке, то за 100 запросов мы получим нехилую экономию. Даже при учете, что допустим сам скрипт работает еще столько же.
А насчет TIDY я еще не думал честно говоря… Кстати есть мнение, что нужно не только JS, но и CSS и HTML отдавать в «minified» виде. Не удобно при разработке, зато после публикования можно смело врубать.
Сжатие DEFLATE: 8.84 КБ → 2.78 КБ (68,6%)
Полное время выполнения: 0,051 сек.