Новая тема   Ответить

 Sams
Кто-то может ПО ОПЫТУ сказать - насколько велика нагрузка на сервак от SSI?

Например: сайт, 100к/сутки. Если заменитьть чистый хтмл на схтмл в котором 100-200 подстановок типа Код: - насколько сильно вырастет нагрузка?

 BAD guy
100-200 подстановок на одной странице чтоли!??

лучше отпиши в саппорт хоста от железа сильно зависит

 lega_cobra
Sams писал:

При работе с переменными в тысячи раз легче, нежели php. Это если отпотолочно судить. Ну и в сотни раз легче, нежели rewrite. Там идет прямой парсинг страницы очень простым кодом с прямыми подстановками.

 Sams
Понятно, спасибо за инфу.

 Stek
Цитата:
Вообще то страница с инклудами на пхп и простой хтмл по скорости будут процентов на 20 всего отличатся.

Но я думаю мало кого будет волновать факт, что сервер вместо 600 страниц за секунду сможет отдавать только 500 или даже ( о господи, падение в 2 раза ) всего 300. При трафике в 1лям в час уже возникают совершенно другие проблемы

 lega_cobra
Stek писал:

При этом только одна libphp по размеру раз в 5 больше, чем остальная апача со всеми остальными модулями... А это уже сильно влияет на кеширование в памяти страниц, и, соответственно, на отдачу.

 Stek
ну это уже другой вопрос

Сейчас везде на хостингах пхп модулем по умолчанию, поэтому выбор SSI или PHP в таком случае не существенен.

А так, для статики, наверное nginx лучше поставить.

 Sams
Меня, в первую очередь, интересует нагрузка на проц.
nginx - не решение. В смысле - он не везде есть. Все должено работать и на виртуалах, в том числе.

 lega_cobra
Sams писал:

Проц грузит обычно mod_rewrite

SSI проц не грузит.

 zuborg
Ещё как грузит
Скорость отдачи различается почти на порядок
Раз в 3-5 минимум, и это ещё немного SSI-тегов
Просто чистая статика отдается исключительно быстро, если правильно настроить сервер, конечно )

 Stek
Сейчас время такое - процессор грузить. Ну разве что только галерки и фришники в статике отдавать.

 lega_cobra
Боюсь показаться не очень вежливым, но еще раз замечу, что прямой линейный парсинг ну уж никак не грузит процессор. А скорость отдачи зависит скорее от интенсивности дисковых операций и занятости дискового кеша.

 zuborg
Ну, во первых парсинг все же грузит проц, как ни крути
Скопировать пачку байт можно гораздо быстрей чем поискать там тег и сделать соотв действие, которое опять же далеко не бесплатное, особенно если использовать не include file а include virtual или include exec
А если использовать sendfile для статики то и копировать эту пачку байт не надо - ядро само подрывает контент с винта (если он ещё не в памяти) и пишет в буффер сокета либо сразу отдает сетевухе через dma, если есть поддержка zero_sockets
А во вторых, сам факт обработкой SSI, даже если нет ни одгого SSI-тега, уже добавит ощутимый оверхед и замедлит выдачу на время порядка миллисекунд, что автоматом уменьшает максимальный rps

С другой стороны, SSI куда меньшее зло, чем
AddType application/x-httpd-php .html

Но правильней всего сгенерить контент один раз и положить его на диск в тот же index.html
Жаль что никто до сих пор не озаботился соданием нормального кеширующего шаблонного движка

 Sha
zuborg писал:
Я пользую самопальный. И видимо не я один.

 Stek
Цитата:
Их очень много , особенно самопальных.
Но тогда возникает вопрос, а нафига городить огород с кешированием, когда можно тупо пустить через сквид и получить гораздо значительнее выйгрышь.

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

 zuborg
Через сквид далеко не всегда нормально получится закешировать так как надо, а не так как хочется сквиду

Принцип таков что не надо делать много раз работу по рендерингу контента, которую можно сделать один раз и пользоваться дальше результатом столько раз сколько надо.
Какие могут быть тут проблемы ?

 lega_cobra
zuborg писал:

Замелдляя выдачу в 3-5 раз??????

Все, я молчу...

 zuborg
правильно, лучше потестить, сколько запросов в секунду апач сделает с SSI и сколько без, а потом говорить