Ты отстал от жизни))) Коньюнктура диктует свое, и в моем движке есть ООП в его самом злокачественном проявлении. И да, он теперь похож на фреймворк.

Однако это движок для обычных сайтов, не для высоконагруженных. И от классических фреймворков отличается тем, что в его ядре собраны только те функции и классы, которым нет аналогов в PHP. Допустим функция htmlspecialchars() не может работать с массивами. А моя обертка htmlchars() может. Если бы первая могла, не стал бы я писать свою. А вот классические фреймворки зачастую просто подменяют одна другую, добавляя быть может только расширенный дебаггинг. Что важно только на стадии разработки, и остается в приложении на всегда. И потому классические фреймворки и получаются тормознутыми и ресурсоемкими.

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

А под твое определение фреймворка можно подвести любое, более-менее внятное приложение. Неужели кто-то в здравом уме и рассудке будет в каждом приложении снуля писать пагинатор или почтовый класс. Конечно будет собрана библиотека готовых решений. Однако если не зажиматься в рамки, можно использовать любые наработки. А фреймворк диктует свои законы. Да, можно конечно расширить его и своими наработками, в чем тогда его смысл вообще?

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

Уж лучше спроектировать самоделку из готовых, проверенных агрегатов, подгоняя один к другому и дополняя эксклюзивными деталями, чем пытаться сделать боллид формулы 1. взяв за основу москвич 412.

Так что мимо. Структура - еще не значит фреймворк. И без структуры никак. Но высоконагруженные проекты лично я не стал бы обременять костными правилами фреймворков.

Это не сарказм. Это пример из жизни. Лично я с этим сталкивался. И я же написал - пример вопиющего безобразия. Есть моменты гораздо прозаичнее, которые и не разглядишь сразу. Ибо инкапсуляция. Не лезь в фреймворк, не твоего ума дело. А там может все что угодно твориться.

На высоких нагрузках код должен быть максимально прозрачным и управляемым. Каждая секунда простоя, как серпом по фаберже. А фреймворки прозрачностью не блещут, увы. Или ты хочешь сказать, что с закрытыми глазами знаешь, как устроен ZF в любой его части?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

на высоких на грузках я и не спорю, но на всех остальных проектах, ты выигрываешь в скорости разработки, а значит в деньгах, а его тормазнутость не когда не кто не узнает о ней т.к. НАГРУЗОК не будет, люди вы о чом джумлу половина студий юзает которая со стороны сткорости вообще черепаха.

Я понимаю это так. Знать и умение работать с memcache(d), redis, какие-то nosql базы, реплика mysql, оптимизация, клиентская оптимизация. Ещё по тему можешь почитать тут http://www.insight-it.ru/highload/ может чего ещё надумаешь.

Это ты про какую часть????

Величина нагрузки - вещь относительная. Вконтакт тот же к примеру имеет столько серверов, что ежедневно меняют 8-10 жестких дисков. У них одна нагрузка.

Кто-то ограничен в ресурсах, и для него 1000 уников в сутки - уже нагрузка.

Твой подход - рвануть бабла, а дальше не мое дело, имеет конечно место быть. И почему то часто поборниками фреймворков выдаются за плюс. Но есть еще и обслуживание. Не только разработка. Так вот, повторюсь. Фреймворк выгоден только на стадии разработки и выгоден в первую очередь исполнителю. Заказчик тоже может сэкономить, но скупой платит дважды. Сэкономив на разработчиках, он рискует потратиться на сервера, если популярность его ресурса превысит ожидания.

А раз мы тут пытаемся рассмотреть действительно большие нагрузки (для меня это от 1000 запросов в секунду, с такими проектами приходится работать), то сторона обслуживания мне знакома не по наслышке. И этот аспект в частности.

Хотя это дело этики и совести скорее. Желание заработать побольше - вполне законное желание.

По сути что могу сказать. Нужно стараться как можно больше разгрузить СУБД, перекладывая максимум вычислений на сторону PHP. На первый взгляд абсурд - сервера БД работают быстрее. Однако однопоточность их сводит на нет выигрыш по скорости.

Можно коротеньким запросом получить данные, а потом долго обрабатывать в несколько потоков на стороне PHP, а можно слепить один сложный запрос и забить очередь.

А на стороне PHP стараться поменьше использовать перезаписей. Чем кстати очень грешат фреймворки. Это ускорит процессы и сэкономит память.

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

UPD ApuktaChehov опередил чутка.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Нет ну если вы все такие хорошие и строите системы за мизер, любому заказчику под высокую нагрузку то флаг вам со своим движком) И мой подход выполнить требования тз, а не выделываться на весь белый свет пол года что я умею писать

Просто есть требования к каждому проекту при таких то ресурсах держать такую то нагрузку. И если заказчик не бродяга с улицы то хостинг за 5к в год позволить себе сможет, а туда уже любой двиг заливай хоть джумлу хоть ZF. Вытянит.

Именно об этом сейчас читаю в той книге, которую рекомендовал выше (первая страница). Благо, тут все понятно.
Не понятно следующее: смысл репликации (дублирования), вот тут-то я закипел

VELIK505, спасибо за точный, лаконичный ответ!

_____________
Гнусный социопат с комплексом Бога.

Разносят на минимум не 2 сервера, один мастер (в него только пишут insert update), а все остальные серваки выводят (select), данные реплицируются с мастера (на который пишут) на слейвы (которые выводят).