Что быстрее статика или MySQL

Думаю, что простые html будут меньше всего грузить сервер. Но это не удобно, если приходиться менять шаблон (да и просто прикреплять шаблон) и организовывать поиск. Я бы предпочел хранение в базе с последующим кэшированием в виде основного тела страниц и последующим инклюдом. Т.е. рекомендую совместить методы.

MySQL это те же файлы, только работа с ними огранизована достаточно хорошо.

Тут нужно смотреть, смотря как организовывать.

Думаю, что если всё сделать корректно, то mysql может быть быстрее.

Himiko, +1

MySQL всю эту мелочь может в памяти держать и тогда обращений к HDD может не быть вовсе.

НО, с посещаемостью 1-50, думаю, он не станет держать это в памяти )

Я бы выбрал статику, если нет нужды в обновлениях.

Тоже так думаю, но пока только сомнения.

А как вы думаете - нужно делать 200 баз (по 8-100 записей) на 200 сайтов (на будущие 1000-2000) на сервер на котором будет 1н диск (возможно даже не серверный) или все это держать в 1й базе на 100 000 записей с индексом по 2м полям (что за страница и что за сайт) чтобы не плодить мелкие файлы.

PS.

И какое количество сайтов такого уровня сможет выдержать сервер на основе 4х ядер + 8ГБ оперативки + 1 HDD (почему-то у меня такое чувство что упираться все будет в жесткий, или я ошибаюсь?)

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

MySQL хранит каждую табличку в отдельном файлике (а точнее в нескольких файликах).

И в память грузит таблицу целиком.

Поэтому, мне кажется, целесообразнее делать всё вообще в одной таблице.

100-200 тысяч записей — это вообще копейки, и проц 4-ядерный (даже Core2) будет отлично их лопатить.

Тонкое место тут HDD, поэтому нужно метить, чтобы вся эта табличка умещалась в память.

Если у Вас 50*100*200=1.000.000 запросов в сутки максимум (10 запросов в секунду), вопрос как хранить действительно есть. Нагружать минимально будет, ИМХО, хранение текстовых статических версий и отдача их nginx'ом. Ну или полное кэширование - то есть index.php отдаёт страницу при её наличии на диске в кэше или переделывает и сохраняет в кэш. Надеяться что mysql будет что-то хранить в памяти не стоит, так как запросов маловато и повторяющихся практически не будет.

html + отдача nginx'ом быстрее некуда

mysql это дополнительные грабли на подключение и работу самого демона, проще дать nginx'у больше памяти под буферы.

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

Эти куски включаю в код страниц вызовом PHP команды readfile().

readfile() – работает быстрее чем include(), так как readfile() не производит синтаксический анализ содержимого файла.

Когда фрагменты сайта нужно изменить, то запускается скрипт, который на основе данных из mysql генерирует HTML фрагменты.

В некоторых местах скрипт для изменения HTML файлов запускается сразу после внесения изменений в mysql.

А в некоторых местах скрипт запускается по крону. В результате, между изменением mysql и изменением на сайте происходит некоторая задержка.

Такая конструкция работает на сайте с 1,3 миллиона кликов в сутки.

zexis, хранить полностью собранные html файлы слишком накладно по объему? Почему использовалось решение с php, тянущем отдельные фрагменты?

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