-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
symfony: генерация страницы 150мс
- Автор темы nerezus
- Дата начала
gray07
Новичок
Нет, ускорится только разбор интерпретатором пхп файлов, а у симфони там много кода, и с phpdoc комментариями.
К тому же, часто более 80-90% времени выполнения занимают запросы к БД, если сайт настолько серъезный, что стоит юзать фреймворк.
И наконец
>The speed of a framework is not the most important argument
Angerslave
Новичок
Вот с этого места можно поподробнее?
atv
Новичок
Обоснование я уже не раз приводил в других топиках. А предложить лучше... могу, но, как говориться, нет пророка в родном отечестве.
Лучше, для меня, это работающий функционал, и примеры кода. А для Symfony и Doctrine, как ты мог прочитать, это документация. Только вот документация, которая не подкреплена работающим функционалом, это как телега впереди лошади. Толку от неё мало, и ответы приходиться искать на форумах, или методом тыка. Всё это я уже прошёл, работая с Symfony.
В тоже время, качественный код с примерами работы я понимаю значительно лучше, чем тома документации, и ценю значительно выше, так как, даже в случае бага, его легче локализовать и обойти.
Wicked
Новичок
Во-первых, речь в топике изначально шла про symfony, а не про doctrine. Старайся придерживаться темы.
Во-вторых, один приведенный тобой пункт не может автоматически низводить symfony до ранга говна.
В-третьих, конкретно у symfony есть, может и не идеальный, но достаточно хороший туториал - askeet. Чем не рабочий функционал? Да и сама дока symfony везде, где можно, снабжена примерами.
Во-вторых, один приведенный тобой пункт не может автоматически низводить symfony до ранга говна.
В-третьих, конкретно у symfony есть, может и не идеальный, но достаточно хороший туториал - askeet. Чем не рабочий функционал? Да и сама дока symfony везде, где можно, снабжена примерами.
Bakti9rov
!*|=?
ну так В РЕЛЬСАХ отличие от продакшена - это токо логи, бенчмарк и дебаговые средства.Автор оригинала: Gas
Bakti9rov
ну это что-то сильно брутально, может develop mode стоитили тачка совсем дохлая - рельса ресурсы любит.
0.4-0.6 с - цифра реальная даже для рельсового "хэллоуворлд", при том что загруженный в память из Монгреля фреймворк остается "висеть" от сессии к сессии, обрабатывая другие запросы.
Для обычного CGI ваще жопа - поднятие отдельного процесса, загрузка фреймворка, запуск приложения, это как минимум секунда-полторы.
nerezus
> В общем вывод такой: либо придется терпеть жуткие тормоза, либо юзать Django/Turbogears/RoR ... но потерять пхп
вообще, стоит еще подумать... в других фреймворках (тем более на другом языке) - свои "черные ящики"... это нужно копаться и пробовать. Считаю 150мс нормальным для такого фреймворка как симфони... это же все-таки не какая-нибудь "мелкая CMS на файлах".
Gas
может по одной?
ещё почти весь исполняемый код (не уверен насчёт views) берётся из памяти, а не заново читаются файлы,парсятся и т.д.
Уверен что есть ещё вещи влияющие на производительность, так-как разница между этими environments очень существенна.
Но я согласен c тем, что обладая опытом в php и при отсутствии оного в ror, менять symfony на ror для создания нового проекта прямо сейчас - не лучшая идея. А вот в целях расширения кругозора, на конкурентов смотреть стоит.
atv
Новичок
А я именно о Симфони и говорю, Доктрина своё получила в другом топике
Я же говорю, что уже не в одном топике обосновывал своё мнение.
Ок, давай ещё добавлю.
Думаю не ошибусь, что основными частями фрэймворка являются DBAL, какой нибудь Template Engine, MVC или другая архитектура, и хорошо бы ещё ORM.
Вот и считаем: DBAL и ORM у Симфони позаимствованные, Template Engine у него нет. Остаётся MVC, которая, в свою очередь, полностью опирается на DBAL и ORM. Это к вопросу о том, что речь идёт о Симфони а не Доктрине.
Далее, основное назначение фрэймворка, это повышение реюзабельности кода, причём не столько входящего в сам фрэймворк, а написанного прикладным программистом, использующим фрэймворк. А для этого должна быть обеспечена гибкая архитектура. А этого у Симфони нет. Она офигетительно конфигурируемая, но это не тоже самое что гибкая. Если привести аналогию, то конструктор Лего - это гибкая архитектура. Из разных деталей с определёнными интерфейсами ты можешь составлять более сложные конструкции. А Симфони - это как система запуска ракет, в которой тысяча ручек, которые можно покрутить и подёргать, но добавить или отнять что-то очень сложно.
Конфигурируемость означает, что в коде ВСЕГДА присутствует логика по обработке этих конфигураций. Вот и получаем "Hello World" в 150 мс.
За что ещё можно положить глаз на Симфони, и что может повысить реюзабельность кода, так это генератор админки. Но, именно он остаётся слабым местом, с большим количеством глюков. Плюс недочёты в подходе. Чтобы сменить дизайн, нужно либо переопределять сгенерированный шаблон целиком, либо переписывать генератор. Использование ORM вместо какого нибудь Грида для построения HTML таблиц приводит к неоптимальному количеству SQL запросов.
Мне больше импонирует компонентная архитектура, которая, к тому же, позволяет легко создавать собственные компоненты и, таким образом, повышать реюзабельность кода.
Да, с говном я погарячился. Скажем так, не совсем удачное решение.
gray07
Новичок
И с неудачным решением тоже. А если мне например нужен не конструктор, а именно готовый каркас, чтобы не заморачиватся с ним, а просто дальше реализовывать логику приложения? я юзер неудачного решения?
Нравится вам заново "конструировать" каждый свой сайт - ваше дело, но не все так делают.
А что, в симфони не так?
Wicked
Новичок
твоего - может быть.
В симфони это как минимум: symfony sync, кэширование, конфигурирование (ага, yaml можно использовать и в своих целях), движок кэширования, движок хранения сессий в многочисленных бд, i18n, управление логами, фреймворк для юнит- и функционального тестирования, autoload с кэшированием, таски, дебаг-панель, движок форм, роутинг, ...
Одним словом - ты ошибся
Тоже спорное утверждение. То, что в качестве темплэйтов используются php-файлы, еще ни о чем не говорит. А хелперы? А автоматический эскейпинг данных? А всякие слоты/компоненты?
думаю, файл factories.yml ты в глаза не видел, и вот эту статейку ты тоже не читал.
atv
Новичок
Когда я говорил, что погарячился, я имел ввиду, что в принципе, любой опен сорс проект не заслуживает такой оценки. Но это не означает что я изменил своё мнение о Симфони.
А кто говорил что заново? И кто говорил что все так должны делать? Я говорил о конкретных недостатках Симфони. А уже каждый волен сам выбирать.
Нет, не так.
Ну так это всё существует и в виде библиотек, и многое из того что ты назвал, Симфони, таки, использует чужое. А фрэймворк это не библиотека. Те части, которые назвал я, это наиболее сложные части, и которые более тесно интегрированны в общую архитектуру фрэймворка.
Template Engine либо есть, либо его нет. Попробуй повторно использовать код шаблонов Симфони, или реализовать компонент типа Grid.
Видел и читал. Что характерно, в Симфони появился класс sfEventDispatcher. Это пример того, что Симфони начинает двигаться туда, где другие уже находятся. Дошло таки, наконец, и это после десятилетнего опыта веб-разработки, которым аргументируют авторы свои решения.
atv
PHP сам по себе есть Template Engine, по этому в симфони Template Engine есть и при том хороший.
Ну и что? Если есть готовое и качественное, то зачем изобретать свой велосипед?
Это каким местом оно опирается? А если модель это не база, а какое-то хитрое хранилище основанное на чем-то типа RPC (типа оболочка вокруг клиентов к какму-либо сервису) то в данном приложении архитектура MVC вообще не применим?
Может быть вы просто не умеете готовить ORM? Я сейчас использую на работе симфони и doctrine и что-то не замечаю огромного количества запросов.