Feb 06

Propel – преимущества и недостатки

Web, Программирование, Работа Add comments

В процессе написания сайта с использованием Symfony начали проявляться недостатки этой замечательной, на мой взгляд, библиотеки…

Первое, о чем хочется сказать - очень удобно реализованы связи one-to-many. Propel сама сгенерирует базовые классы, в которых такие связи будут учитываться изначально. Пользоваться очень удобно, своего кода в моделях приходится писать очень мало, а если быть более точным - почти весь код в данном случае получается именно product-specific. В случае со связями one-to-one проблемы появляются - как я этого ни добивался, Propel упрямо считает эти связи такими же, как и one-to-many и генерирует неправильный код. Исправляется обычно дописыванием правильных функций вручную, благо, обычно дописать только get<PrimaryKey>-функции. В моем случае я вообще перестроил БД так, что таких связей у меня не оказалось, так что конкретного ничего сказать не могу.

Второе - “всё - обьекты”. Очень популярное в ООП высказывание подходит к Propel’у просто замечательно. :) Работа с Propel’ом заключается исключительно в работе с обьектами-записями и обьектами-таблицами. Никаких php’шных массивов (привет CI и CakePHP), одни классы и обьекты. Очень удобно. С эффективностью, правда, могут возникать огромные проблемы. Я, кстати, так до сих пор и не знаю, как эффективно выбрать (категория + количество продуктов в ней) за один запрос. Но беспокоиться об этом я буду уже потом. :)

Блин, вот сидишь на работе и думаешь - сколько всего можно написать, плохого и хорошего, а приходишь домой и нифига не вспоминается.

Третье - many-to-many. После того, как у меня появились такие связи, я начал очень сильно жалеть о том, что я не выбрал Doctrine… По сравнению с ней (она дополнительную many-to-many таблицу создает сама и сама же за ней следит) в Propel’е всё ужасно - приходится создавать вручную таблицы и дописывать в них целую кучу кода, который бы вполне могла дописать сама библиотека в базовых классах. Может в том же CI это вполне нормальным кажется (контраст другой), но здесь, когда строишь модель базы данных - мыслишь исключительно в обьектах, которые тебе будут нужны. И добавлять (а еще сопровождать) эту [непонятно откуда взявшуюся, в реале-то её нет] таблицу очень неудобно.

Четвертое - опять по сравнению с Doctrine’ой - нет возможности “опускаться” на уровень SQL не теряя ORM’а. Т.е. либо Propel ORM, либо Creole (PDO). В Doctrine’е есть для таких случаев DQL - достаточно удобная штучка, если поглядеть по мануалу. Вообще, Doctrine, на мой взгляд, гораздо более функциональная, мощная и удобная библиотека. Да и User Guide’ы у неё гораздо более полные и, как ни странно, user-friendly.

Но по сравнению со всем остальным, что я видел на PHP - Propel - это очень круто.

written by FX Poster \\ tags: , ,

One Ping to “Propel – преимущества и недостатки”

  1. Doctrine » Блог FX'а Says:
    January 31st, 2009 at 02:33

    [...] неделю работаю с Symfony 1.2 и Doctrine. Так вот, если раньше я хвалил Doctrine, то теперь… В общем, после нескольких дней работы с [...]


27 Responses to “Propel – преимущества и недостатки”

  1. 1. larin Says:
    February 7th, 2008 at 00:24

    FX Poster, привет!
    Ответь мне на один вопрос: какое железо потребуется под сайт с нагрузкой, примерно, 4 000 000 – 5 000 000 хитов в сутки, с использованием Propel или Doctrine?

  2. 2. FX Poster Says:
    February 7th, 2008 at 00:34

    На самом деле после ~500 000 хитов в сутки начинаются проблемы с любыми фреймворками, ИМХО. :)

    Если судить по тому, что сейчас есть – обычный хостинг, даже не VPS выдает ~150-200 ms в debug-режиме на запрос. В обычном – ~100ms. Если врубить APC – у меня получилось ускорение в ~4 раза. Т.е. 25-35 ms на запрос.

    Считаем – в секунду – 30 запросов. В сутки – 2 592 000 запросов. Возьмем 1 000 000 запросов. И это на обычном хостинге. Правда, хостингов с APC на самом деле довольно мало.

    PS. Я разрабатываю сайт отнюдь не для таких количеств посетителей. Для высокой посещаемости больше всего подходит Django, если говорить о динамических языках. Иначе – дорога к ASP.NET или Java.

  3. 3. FX Poster Says:
    February 7th, 2008 at 00:39

    Да, кстати. У меня хостинг тоже без APC. APC я тестировал у себя дома, на Ubuntu.

  4. 4. bill Says:
    February 7th, 2008 at 06:57

    Иначе – дорога к ASP.NET или Java.

    с хера вдруг? оно всё само там залетает на ASP.NET или Java?

    имеено так и посчитали на facebook, где 5 000 000 – это просто детская нагрузка. там мимимум 5 000 000 уников в день… и всё крутится на PHP…. учите мат часть……

  5. 5. larin Says:
    February 7th, 2008 at 10:18

    @FX Poster
    >> На самом деле после ~500 000 хитов в сутки начинаются проблемы с любыми фреймворками, ИМХО.

    Не скажите, если FW писался специально под такие сайты, то с ним все нормально будет =)

    >>Считаем – в секунду – 30 запросов. В сутки – 2 592 000 запросов. Возьмем 1 000 000 запросов. И это на обычном хостинге. Правда, хостингов с APC на самом деле довольно мало.

    Ты взял и распределил нагрузку равномерно в течении всего дня, но такого ж не бывает.
    А в пиковые часы 30 запросов в секунду, это ОЧЕНЬ мало.

    @bill
    Полностью согласен! +1 )))

  6. 6. FX Poster Says:
    February 7th, 2008 at 10:36

    bill
    учите мат часть……
    Сказанул, молодец. Давай линки.

    оно всё само там залетает на ASP.NET или Java?
    Что значит “само”? Я говорю о том, что та же Java сама по себе быстрее PHP. И все.

    larin
    Не скажите, если FW писался специально под такие сайты, то с ним все нормально будет =)
    Вообще-то, для таких сайтов фреймворки не используют.

    А в пиковые часы 30 запросов в секунду, это ОЧЕНЬ мало.
    Да, я догадываюсь (правда о реальном распределении я очень смутно догадываюсь). И что? Я ж не спорю с тем, что оно просядет, я о другом.

    Это совершенно не означает, что этими технологиями не нужно пользоваться. Вот я и пользуюсь.

  7. 7. larin Says:
    February 7th, 2008 at 10:54

    @FX Poster
    >> Я говорю о том, что та же Java сама по себе быстрее PHP. И все.
    И давно?

    >>Вообще-то, для таких сайтов фреймворки не используют.
    Это кто тебе сказал?

    >> Это совершенно не означает, что этими технологиями не нужно пользоваться.
    Блин, я же не призываю ими не пользоваться. Я просто с ними никогда не работал и решил узнать о скорости… Все-таки хочется в свой FW нормальную ORM, но видно не судьба =(((

  8. 8. FX Poster Says:
    February 7th, 2008 at 11:03

    И давно?
    Спорить будешь?

    Это кто тебе сказал?
    Скажем так – один умный человек из Percona.

    Я просто с ними никогда не работал и решил узнать о скорости…
    Далась вам эта сверхскорость… У тебя все сайты поголовно по миллиону хитов в день получают?

  9. 9. Andrey aka Patrick Says:
    February 7th, 2008 at 11:12

    Вы сначала определитесь что для кажного означает слово FW. А то такое впечатление что вы про 2 разных понятия общаитись….

  10. 10. FX Poster Says:
    February 7th, 2008 at 11:16

    Смотрим wiki. Каркас для application’а. В случае со сильнонагруженными сайтами – там такого каркаса практически (или вообще) нет.

  11. 11. Andrey aka Patrick Says:
    February 7th, 2008 at 11:23

    Незнаю, кто как разрабатывает, но у нас он есть. Таже хабра тоже использует свой FW…

  12. 12. larin Says:
    February 7th, 2008 at 11:24

    >> В случае со сильнонагруженными сайтами – там такого каркаса практически (или вообще) нет.
    Вот тут ты не прав, и “умный человек” либо слукавил, либо ты его не так понял ))))

    >>Спорить будешь?
    Нет не буду, времени нет ))

  13. 13. FX Poster Says:
    February 7th, 2008 at 11:26

    Свой фреймворк иметь невыгодно. Его нужно еще и поддерживать. В то время как другие фреймворки имеют своё комьюнити и очень много удобных и полезных фич.

  14. 14. FX Poster Says:
    February 7th, 2008 at 11:28

    У нас на работе тоже был “фреймворк”… Я его с удовольствием сменил на symfony. Ничуть не жалею.

  15. 15. Andrey aka Patrick Says:
    February 7th, 2008 at 13:15

    @FX Poster использовать чужые, так же не полезно(если ты не входич число разработчиков).
    Чужие баги, низкая производительность….

  16. 16. FX Poster Says:
    February 7th, 2008 at 13:23

    В корне не согласен. Использовать всё свое – это просто полный бред. Какой толк в очередной раз изобретать велосипед, если его уже изобрели и добавили туда кучу полезностей.

    Нормальный строитель никогда не будет заново придумывать кирпич. Он просто его будет использовать по назначению (хотя никакого участия в “разработке” кирпича он не брал).

    Нормальный программист поступит точно так же – зачем изобретать, если есть уже написанное (кстати, а зачем вообще php нужен? можно же и на ассемблере писать!).

    Если вы так не делаете – ваше право. Теряете вы гораздо больше чем получаете.

  17. 17. Денис Радченко Says:
    February 7th, 2008 at 19:31

    Спасибо за пост. Все никак не перейду на ORM, SQL пока ближе :)

  18. 18. Ali Says:
    February 7th, 2008 at 22:57

    Думаю, все знают, но все же напомню: Yahoo Bookmarks построена на symfony. И еще, чаще всего так бывает, что самой нагруженной является база данных, а не фреймворк… Поэтому все, что только можно кэшируется. И вот чего явно не хватает symfony, так это работы с memcached…

  19. 19. FX Poster Says:
    February 7th, 2008 at 23:16

    Я не знал, кстати. :)

    Насчет memcached – а это что?

  20. 20. Блогер Says:
    February 9th, 2008 at 12:40

    sql определенно ближе..

  21. 21. Pastor Says:
    May 6th, 2008 at 09:50

    FX Poster, забыл про Code Complition в IDE, это тоже конкретный плюс для Propel. В случае с Доктриной все поля надо вбивать по памяти :(

  22. 22. FX Poster Says:
    May 8th, 2008 at 23:25

    Я тебе скажу по секрету, что я на работе никакими IDE’шками не пользуюсь. :) Юзаю Intype – сниппеты рулят. На новом материале – да, автокомплит очень помогает, но когда работаешь с одним и тем-же долгое время – уже помнишь наизусть почти все функции и т.д. – и сниппеты выходят вперед.

  23. 23. Ali Says:
    July 19th, 2008 at 16:06

    Спасибо за наводку, memcached плагин как-то не замечал (хотя пока особой потребности не было), в принципе очень интересно его пощупать, может даже можно прикрутить к Propel behaviours…

    К стати, полезный совет. Если есть возможность, попробуйте перейти на использование unix sockets для БД в symfony (да и не только в ней). После переключения наблюдалось заметное сокращение времени отклика на запрос (в принципе неудивительно – исключается сетевой уровень взаимодействия, но я как-то раньше делал по старинке, через tcp).

  24. 24. FX Poster Says:
    July 19th, 2008 at 22:14

    Если есть возможность, попробуйте перейти на использование unix sockets для БД в symfony (да и не только в ней). После переключения наблюдалось заметное сокращение времени отклика на запрос (в принципе неудивительно – исключается сетевой уровень взаимодействия, но я как-то раньше делал по старинке, через tcp).
    Вряд ли я буду этим заниматься – человек я всё-же ленивый. Но идея интересна – ссылками или примерами, как это делать не поделишься?

  25. 25. Ali Says:
    July 19th, 2008 at 22:54

    Да все просто.
    Для symfony надо добавить в databases.yml два параметра в раздел param (потом, понятно, скомандовать ’symfony cc config’):

    all:
    propel:
    class: sfPropelDatabase
    param:
    …….
    protocol: unix
    socket: /var/lib/mysql/mysql.sock #правильный путь к сокету

    Пример тут http://www.symfony-project.org/forum/index.php/t/13044/

    Если подключение через PEAR то там нужно DSN сформировать типа такого:
    mysql://user@unix(/path/to/socket)/database

    Узнать путь к сокету можно в phpinfo() либо в настройках mysql.

  26. 26. FX Poster Says:
    July 20th, 2008 at 00:45

    Спасибо, может как нибудь попробую. :)

  27. 27. DmitriKadykov Says:
    April 30th, 2009 at 16:00

    > Я, кстати, так до сих пор и не знаю, как эффективно выбрать (категория + количество продуктов в ней) за один запрос.

    http://snippets.symfony-project.org/snippets/tagged/criteria/order_by/date

    Второй пример как раз об этом.

Leave a Reply