Отличный доклад, посмотрел видео полностью. Не знал, что похапе уже так сильно подрос. Очень интересно теперь делают видео-презентации.
Кстати, по содержанию. В последнем примере объект Olja имеет две связи, а Masha одну. Наверно потому что Olja.boobs_size = 5 в то время как Masha.boobs_size = 1 🙂
Интересный доклад, только как-то забили упомянуть Symfony которая и породила Doctrine. И, кстати, утверждение о том, что Doctrine однозначно лучше чем Propel довольно спорно. Просто SensoLabs сейчас пропихивает свою технологию. Во всяком случае это актуально для версии 1.Х
И я всётаки не понял каким образом весь этот микс технологий справляется с нагрузками? По идее чем больше прослоек — тем медленее система в целом (больше требухи подгружать для каждого запроса). Кэширование, конечно помогает, но не является панацеей. Ведь AOP, ORM и.т.д. созданы для быстрого девелопмента и удобной поддержки, а не для перформанса.
хехе 🙂 Женя, не тебе бы о _спорных_ утверждениях говорить :)))
Александр наверное имел в виду что перформанса им хватает. врядли тут имелся в виду мега-нагруженный портал. в таких случая методики уже просто другие..
Про перформанс:
Пока код работает быстрее чем запросы к базе. Проблем не возникнет. Как правило даже с кучей прослоек запросы к базе/кешам/файловой системе занимют львиную долю времени запроса.
А вообще какой бы не был медленный код, если его распаралелаить на n нод, где n = количество пользователей / количество пользователей, которое может обслужить одна нода, то проблем с перформансом не будет (за исключением централизованных БД).
scalability != быстрый код
scalability == способность кода масштабироваться
ORM, DAO и AOP и другие прослойки какраз таки и упрощают распаралеливание т.к. не приходится менять код чтоб поменять технологию хранения данных или конфигурацию хранилища.
W32Blaster
Отличный доклад, посмотрел видео полностью. Не знал, что похапе уже так сильно подрос. Очень интересно теперь делают видео-презентации.
Кстати, по содержанию. В последнем примере объект Olja имеет две связи, а Masha одну. Наверно потому что Olja.boobs_size = 5 в то время как Masha.boobs_size = 1 🙂
Jevgeni Goloborodko
Интересный доклад, только как-то забили упомянуть Symfony которая и породила Doctrine. И, кстати, утверждение о том, что Doctrine однозначно лучше чем Propel довольно спорно. Просто SensoLabs сейчас пропихивает свою технологию. Во всяком случае это актуально для версии 1.Х
И я всётаки не понял каким образом весь этот микс технологий справляется с нагрузками? По идее чем больше прослоек — тем медленее система в целом (больше требухи подгружать для каждого запроса). Кэширование, конечно помогает, но не является панацеей. Ведь AOP, ORM и.т.д. созданы для быстрого девелопмента и удобной поддержки, а не для перформанса.
Антон Архипов
хехе 🙂 Женя, не тебе бы о _спорных_ утверждениях говорить :)))
Александр наверное имел в виду что перформанса им хватает. врядли тут имелся в виду мега-нагруженный портал. в таких случая методики уже просто другие..
Jevgeni Goloborodko
У меня вообще тема очень спорная. Только на поспорить времени не хватило 🙁
Но с нетерпением жду всех холиварзиков в комментах к докладу 🙂
Антон Архипов
а, ну так я как нибудь приложусь как минутка выдастся 🙂
Alex Rudakov
Не знал что к моему посту коменты есть :)))
Ответ спустя два года:
Doctine 2.0 лучше.
Про перформанс:
Пока код работает быстрее чем запросы к базе. Проблем не возникнет. Как правило даже с кучей прослоек запросы к базе/кешам/файловой системе занимют львиную долю времени запроса.
А вообще какой бы не был медленный код, если его распаралелаить на n нод, где n = количество пользователей / количество пользователей, которое может обслужить одна нода, то проблем с перформансом не будет (за исключением централизованных БД).
scalability != быстрый код
scalability == способность кода масштабироваться
ORM, DAO и AOP и другие прослойки какраз таки и упрощают распаралеливание т.к. не приходится менять код чтоб поменять технологию хранения данных или конфигурацию хранилища.