Подскажите плизз про движки

Вероятно в таком вот аксепте неправильно понял. Но еще раз - если механизм кэширования доведет контент до статики - какая разница сколько уникального контента? Посещаемость же ТС не упоминалась вовсе. А увязывать посещаемость с количеством контента я честно говоря не стал бы, хотя может быть какая-то корелляция и будет если рассчитывать на случайный трафик.

Мэкс, Вы имеете в виду "многие ко многим" в исходной структуре? То есть что первичная генерация страницы в кэше будет долгой и пока кэш не построиться время "усредненное время ответа" будет то большим, то маленьким (если в кэше уже лежит страница), так? Мне кажется, что это не есть большая проблема, если учитывать тот факт, что "время протухания" для кэша "вообще" шутка бессмысленная. Зачем контенту "протухать"? Право на жизнь имеет только сброс страницы по изменению контента, причем генерация может быть осуществлена тем, кто меняет контент, а не посетителем. Вот это на мой взгляд правильный подход и в принципе не сильно сложный то в реализации. Тем более для простого статейного сайта, где по идее на странице со статьей не так много контенту то еще какого динамического должно быть.

Единственная проблема - первоначальное наполнение кэша, но опять же это наверное для 90% ситуаций не так страшно, если генерация страниц немного потормозит. По идее безотносительно задачи генератор страницы всегда должен быть специализирован под структуру хранения данных, а механизм кэширования почти всегда от нее наоборот не зависит. Хотя, это конечно каждый реализует как хочет.

Про статическое кэширование не понял - почему именно 3-4 раза в день? Интересен путь получения вывода. Сам прикинул, но связи между количеством контента и частотой обновления статического кэша не нашел. Равно как и необходимости его обновлять вообще (если только конструктор кэша вообще не знает ничего об изменениях в данных, это имелось в виду?).

Это тоже неправильно :). Выборка из БД (при использовании индексов, то есть если все сделано не через одно место) по времени никак не зависит от размера БД. Ну, почти, то логарифмическая там зависимость. Также производительность сервера при работе статического кэша будет очень мало зависеть от HDD. Более менее серверные компоненты по степени влияния нужно расставить так (IMHO):

Сильное влияние в зависимости от ситуации могут оказывать:

- пропускная способность интернет-канала на сервере

- пропускная способность шины материнки

- объем памяти

- качество сборки сервера, наличие конфликтов по железу, в т.ч. и удачная совместимость и способность компонентов не мешать друг другу и максимально использовать свои возможности

- охлаждение и блок питания (где-то тут, но не уверен что тут, но уверен что влияние большое и это важно)

- количество процессоров

Среднее влияние, сильно зависит от архитектуры решения:

- винты - скорость чтения

Малое влияние если все корректно спроектировано:

- герцовка процессора

- винты, скорость записи

Что-то в этом духе.

Это что, своего рода пиар, ругаться с потенциальными клиентами? Или вас в детстве не учили общаться спокойно?

stealthy, если бы я обладал временем для расписывания, то, возможно, написал бы почти как Вы ;) Я лишь имел ввиду аппаратный фактор в целом ;)

Хех, действительно сделал скоропалительные выводы насчет увязки кол-ва контента и посещаемости, спасибо что поправили.

x007xx, вы к слову не банк рефератов хотите разместить? Больно уж подозрительное кол-во уникальных статей.

Что за бред, даже sourceforge.net одно время на мускуле стоял (и не тормозил) а там база далека от нескольких гигов (потом перевели обратно на PostgreSQL) 99% проблем с БД заключается в самом движке сайта (организации кеширования, оптимизации запросов и.т.д.)

Ко всем здесь постившим отношусь с большим уважением, но что на самом деле происходит, чем ниже репа и больше скандала, тем больше народу стучится в асью и действительно интересуется CMS.

В том числе беседовал и ТС, не подходит цена.

Но меня заинтересовал контент, из 90 000 статей, это реально уже есть?

Если 90 000 статей готовы, могу предоставить свой движек под Ваш проект бесплатно и выделю место на сервере.

Пример работы движка, на виртуальном хостинге, с базой 350 мегов можно посмотреть тут http://mototorg.d01.ru количеством запросов на страницу, можно управлять.

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

Не забывайте, что у Вас, кроме страниц с контентом, есть еще и индексные страницы. И кешировать, в первую очередь, надо именно их. Страница с контентом отдается достаточно быстро, поскольку там идет запрос к записи к контентом и к кешированным записям с обвязкой. А при запросе к индексной странице происходит обращение ко всей базе данных.

А как система кэшировния определит, что одна из записей индексной страницы была изменена?

А если масштабы работы чуточку выше, чем есть в реальности, то запросы просто игнорируются 😂

http://mototorg.d01.ru/

Дизайн интересный, а вот "внутри" (HTML) - бардак.

У коллеги CMS которая вообще базу не использует: http://www.cmslist.ru/free/trollbase/

Как раз под статьи, если без возмеожности создавать "каменты".

Еще как-то смотрел CMS SAPID (на sourceforge.net), которая все в XML хранит. Разработчики утверждают, что выдерживает 2000 запросов в минуту (или секунду/час/сутки???).