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

Пока-что решил переводить постепенно существующие разделы сайта в CMS нашего ведущего программиста (FenricCMS) - так постепенно переведем весь сайт

тоже неплохой выбор - во-первых он представляет как она работает и всегда все покажет/переделает, во вторых все будет в одном технологическом поле. О CMS не слышал.
Только в этом случае в отличие от того же Зенда все осложняется тем что тратится время на системные тесты. Иначе одна ошибка в библиотечке и например данные в БД летят коту под хвост. Так что все самописы не ленитесь плотно тестировать. Для фреймворков типа Симфони это актуально только для final-end кода т.к. все системные тесты уже написаны, а тут и для ядра. Время опять же.
Короче, это имеет смысл если Вы дальше будете как-то продвигать CMS как отдельный продукт. А ради одного проекта лучше пользоваться готовым проверенным(но не друпал конечно же!)

ИМХО, тут готовыми решениями не обойдешься. А если использовать их, то придется допиливать под себя. Считаю, что лучше с самого начала выбрать пачку разработчиков, которые напишут вам ресурс "под ключ", то есть, под строго вашие потребности, где будет строго тот код, который необходим.

Берете nginx, который будет отдавать статику и проксировать запросы к динамическим страницам - уменьшается нагрузка на бэкенд. Ставите акселератор для кеширования опкода, чтобы интерпретатор каждый раз не переводил ваши скрипты в байткод.

Довешиваете систему кеширования, тот же memcached, в большинство фремворков уже встроили средства для работы с такими системами. На крайняк - можно кешировать в файлы, но ФС все равно медленнее оперативной памяти, если, конечно, вы не будете хранить кеш на RAM-диске. Можно и какой-то NOSQL заюзать.

При таких планах вам, кроме хороших девелоперов и кода, нужен еще и системный архитектор, который продумает нагрузку. Ну, и, соотвественно, админ, который все это чудо настроит.

На портале Кубани форум vbulletin, прекрасно без кэширования держит 100 000 хостов в день ) и даже не лагает :)

ugrastroyinfo, Zend Framework в зубы и поехали

Есть проект, 250 000 уников в сутки, CMS и фреймворков никаких нет. Сейчас данный проект переписывается под второй symfony, что будет - неизвестно, но думается мне, самописные решения намного производительнее всяких там фреймворков и cms.

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

Тут всё дело в том кто ещё пистаь будет и как. Если именно на скорость работы и минимальность потре***емых ресурсов, то нужно очень постараться. Есть куча факторов влияющих на производительность.
Например зачастую в фв, даже с учётом того чо они грузят только то что нужно, у них большое количество вызовов функций пхпшный + поиск и проверки на существование методов и классов, а так же файлов. Если в идеале делать, и быть уверенным что ты используешь именно метод для валидации, а не так как в Yii, который проверит есть ли метод, потом проверит есть ли класс, потом если ли файл. Да, можно оптимальней написать по скорости. Если не использовать текстовые ключи как массивах конфига, тоже будет прирост.
Но есть такая важная особенность, которую упоменул Arks, а именно:

Вот это огромный плюс. Да ещё и готовая продуманная структура для дальнейшего расширения :)
И вообще, очень много тормозов можно получить из за кривой структуры БД. Не просто в несоклько раз, а в сотни раз а может и в тысячи медленней будет работать сайт чем с хорошо продуманной.

С другой стороны, 100 000 хостов в день - это всего лишь 1 запрос к серверу в секунду :) Не такая это и нагрузка. Ещё раз повторю что даже vbulletin без кэшироования прекрасно справляется :)

Замечание модератора: Эта тема была закрыта автоматически ввиду отсутствия активности в ней на протяжении 100+ дней. Если Вы считаете ее актуальной и хотите оставить сообщение, то воспользуйтесь кнопкой или обратитесь к любому из модераторов.