Возможен ли хайлоад на больших фреймворках?

Question

[MegaMufa]

Добрый день.

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

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

Кто работал с высокими нагрузками, поделитесь опытом, оправдан ли отказ от фремворков в этой ситуации?

Answer 1

[Andrey Bazykin]

Highload очень интересное направление. Неплохой цикл статей был в журнале Хакер номер 02/2012 (если не ошибаюсь) от монстров высоконагруженных систем - Highload Lab (Highload).
Так устроен мир программистов, что зачастую проще написать свое, чем дорабатывать чужое решение. Фреймворки создаются для удобства и многие из них не рассчитаны на масштабирование (кластеризацию), да в них есть возможность включить кеширование, но кэширование только отсрочит проблему, в итоге нужно будет заниматься рефакторингом кода, прикручивать разные акселлераторы, но всё прийдет к кластеризации (масштабированию) проекта на другие сервера. Я знаю только один фреймворк, который позволяет делать масштабирование - Битрикс. И как работает это масштабирование я знаю в теории.
Припоминаю ситуацию, когда фреймворк переписывался под высокие нагрузки (это был Yii по-моему). Также существует мнение что MVC не лучшая модель для хайлоад. В общем нужно смотреть по ситуации.

Еще про хайлоад популярных проектов можете почитать тут.

Потратьте день своего времени на освещение этой интересной темы, и сможете ответить на многие ваши вопросы.

Answer 2

[Viktor Vsk]

Хайлоад и высокие нагрузки - это сколько попугаев?

Comments

[MegaMufa]

У каждого свой. У одних - 200К уникумов в сутки, у других - 20К

Answer 3

[kompi]

Мне очень понравился подход 2gis со слоистой архитектурой (есть статья на хабре). В основе фреймворк для быстрой разработки, a потом постепенно можно переписывать отдельные модули на более быстрых ЯП.