Расширения файлов на сайте .html VS .php ?

Извини, не понял. Причем и как "перераспределение"? Ссылка на поддерживаемые директивы бесполезна (я знаю что такое SSI и юзал его ещё в прошлом веке) :)

Шуршание винтом куда напряжнее работой с базой. По сравнению с php (хоть инклудами хоть функциями) - оч сомневаюсь что производительнее. Хотя наверняка зависит от кривости кода.

Откуда на высоконагруженных проектах может взяться профит от убогой технологии? Кто так делает?

SeVlad, допусти, есть у вас какой-нибудь модуль, добавляющий... ну, например, рекламу.

запихиваем их в отдельный файл, кладем на сторонний сервер и проксируем на него запрос.

теперь при <!--# include virtual="/remote/query1.php" --> запрос пойдет на внешний сервер.

на самом деле <!--# include virtual="" --> и без этого приводит к параллелизации запросов.

т.е.

<!--# include virtual="/include/query1.php" -->

<!--# include virtual="/include/query2.php" -->

<!--# include virtual="/include/query3.php" -->

<!--# include virtual="/include/query4.php" -->

породит четыре отдельных потока, причем, в зависимости от настроек энжинкса, эти потоки могут создаваться на разных серверах.

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

А во вторых - ок. инклуд. Чем это будет профитнее того же php-инклуда? Не говоря уже про простой curl с удалённого сайта?

SeVlad, тем, что php штука абсолютно последовательная, исполнение следующего инклуда начинается после окончания работы предыдущего, (Опять-же если не шаманить с курлом.) А ssi инклуд позволяет параллельно исполнить несколько скриптов).

минусики, конечно, тоже есть.

Это практически полная независимость скриптов друг от друга (хотя это и плюс и минус)

Тут уже GET-параметры. Никогда не использую их в канонических адресах страниц статей. Лучше так: /my-article или /articles/my-article

Если php-инклуды использовать только для того, для чего вы описали, это не сильно будет отличаться от SSI. Это все называется сайтом на файлах. И, да, это прошлый век. Для визитки с несколькими страницами, может, еще и сгодится, но для нормального статейника уже нет. Современные сайты работают немного по-другому ;)

апач, mod_rewrite и ЧПУ, и не нужно думать/заморачиваться насчёт всяких там окончаний типа .html или .php

Ну с однопоточностью пхп соглашусь. Однако даже если SSI-инклуды и параллельно исполняется (вот тут не я в курсе, не вникал), то смысла в этом нет - все равно файл с его вызовами читается последовательно.

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

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

В общем как-то не увидел реальных задач, где SSI могло бы давать профит в хайлоад-проектах.

1. Не делайте расширение страницы ни php, ни html. Делайте без окончания (к примеру site/page1/). Во-первых это даст некую свободу в дальнейшем (если нужно будет сменить обработчик). Во-вторых, это даст свободу в названии адреса (ЧПУ).

2. Шапка, подвал и т.д. можно и нужно выносить в отдельные модули. Обязательно отделить шаблон (tpl), где будет только html код, от обработчика (php). Причем это касается всего кода. (это называется отделение логики от кода). Именно так, сразу же! Иначе потом будет сложнее все переделать, а искать и править в смешанном коде дико затруднительно и вообще - это дурной тон.

3. Также делать подключаемые модули, выполняемые основные однотипные операции (то есть чтение/запись из базы/в базу, вывод информации пользователю, файл конфигурации и т.д.). Ибо если потребуется вносить изменения - одна правка в модуле и все. А не лопатить весь сайт - а где же там запросы к базе идут, все переправлять...

Потерялся один мой ответ...

Это был ответ на ваш первоначальный вопрос по поводу использования расширений php vs html. Если вы поместите статик в php-файлы, то будет напрасно тратиться время на обработку этих файлов пыхом. Но, как было сказано, инклуды – это уже не чистый статик. Кстати, без доп. телодвижений они не будут работать в html-файлах. Заставлять Web-сервер отдавать их на обработку пыху – тоже не лучший вариант. Это же когда-то касалось и SSI: для файлов с соотв. инструкциями рекомендовалось использовать спец. расширение. Но сейчас это все история.

Вот от этого и пляшите. Сам на заре веб-шаманства упирался в такие вопросы. Пришёл к выводу, что всё надо начинать с php, тем более нынче поисковикам по барабану, ведь они же знают, что html-файлы могут быть теми же php.

Совершенно верно. Сам заметил такую шнягу, поэтому предпочтительней будет сделать http://www.mysite.com/article/my-article.php или лучше http://www.mysite.com/my-article.php, а ещё лучше использовать не article, а statya.

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