GoldenLine
Zaloguj się
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: doctrine vs propel

doctrine vs propel na podstawie jobeeta: http://www.symfony-project.org/blog/2009/12/07/doctrin...
mnie to specjalnie nie dziwi :-)
Link do wypowiedziLink

konto usunięte

Temat: doctrine vs propel

A jak z porównaniem wydajności? Bo fakt, że łatwiej i przyjemniej jest w doctrine (w propelu można się pokusić o sfPropelFinder ale to nie do końca to samo) tak na prawdę jeszcze mało mówi.

Kiedyś znalazłem coś takiego (można przepuścić przez translator to ogólny sens można wyczytać ;) ):
http://d.hatena.ne.jp/innx_hidenori/20090923/1253677161

W tym teście doctrine wypada, delikatnie to ujme, blado...

Dlatego jakoś nie moge się przekonać do końca do tego orm'a.
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: doctrine vs propel

jeśli chodzi o szybkość, to nie mam większych pretensji, na pewno ma dużo większe zużycie pamięci, ale zawsze jest coś za coś. Sprzęt jest tańszy niż ... :-)
Link do wypowiedziLink

konto usunięte

Temat: doctrine vs propel

Dla małego projektu bez zewnętrznego finansowania oznacza to mniej więcej 8000/rok za hosting zamiast 2000.
To ja póki co posiedze chwile dłużej, żeby popisać w propelu i pomyśle nad sfPropelFinder'em :)

Ale może jak już będzie Symfony 2.0 i kolejny doctrine, to pomyśle nad przesiadką :)
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: doctrine vs propel

ja mam małe projekty hostowane na progreso za 300 zł na rok i działają na doctrine :-)
btw. po zastosowaniu APC, wykorzystanie pamięci spadło momentami bardzo drastycznie.Wojciech Sznapka edytował(a) ten post dnia 07.12.09 o godzinie 13:18
Link do wypowiedziLink

konto usunięte

Temat: doctrine vs propel

Wojciech Sznapka:
doctrine vs propel na podstawie jobeeta: http://www.symfony-project.org/blog/2009/12/07/doctrin...
mnie to specjalnie nie dziwi :-)

Tylko pytanie zasadnicze brzmi:
Ile z tych osób wybiera Doctrine bo jest domyślny (tak jak jak wybierając Propel ja zaczynałem z 1.2) i ze względu na fakt, że twórcy symfony bardziej kierują się na Doctrine.

Założę się, że mała tylko część faktycznie testowała obydwa ORMy pod względem wydajności, łatwości uczenia się, używania itp. i wtedy zdecydowała się na Doctrine.
Link do wypowiedziLink

konto usunięte

Temat: doctrine vs propel

Wszystko zależy od tego co to za projekty ;)

Jakiś czas temu miałem do dokończenia serwis motorowy z wynikami wyścigów.
Od 200 do ponad 1000 rekordów z bazy per strona (samych zapytań niewiele).
Tutaj nawet optymalizacja, cache i eaccelerator niewiele pomagał, bo userzy często dostawali white screen.

To jest właśnie powód dla którego boje się przy wiekszych projektach przesiadać na doctrine.
Ale tak jak mówie, może w przyszłości wraz z kolejną wersją doctrine poprawi się wydajność, a wtedy to już nie będe miał wątpliwości :)
Link do wypowiedziLink
Adam W.

Adam W. senior php
developer, Symfony

Temat: doctrine vs propel

Aleksander Wons:
Wszystko zależy od tego co to za projekty ;)

Jakiś czas temu miałem do dokończenia serwis motorowy z wynikami wyścigów.
Od 200 do ponad 1000 rekordów z bazy per strona (samych zapytań niewiele).
Tutaj nawet optymalizacja, cache i eaccelerator niewiele pomagał, bo userzy często dostawali white screen.

To jest właśnie powód dla którego boje się przy wiekszych projektach przesiadać na doctrine.
Ale tak jak mówie, może w przyszłości wraz z kolejną wersją doctrine poprawi się wydajność, a wtedy to już nie będe miał wątpliwości :)

a to nie jest tak jak z każdym ORM? ORM zamienia rekord z bazy na obiekt. 1000 obiektów to się nie dziwię, że mogło coś nawalić. a jeżeli masz 10, 20 (stronicowanie) rekordów wyświetlanych na stronie to nie ma z tym problemu.
w przypadku, który opisałeś trzeba ominąć obiekty i zwracać tablicę. tak pisali w symfony.
Link do wypowiedziLink

konto usunięte

Temat: doctrine vs propel

Adam W.:
a to nie jest tak jak z każdym ORM? ORM zamienia rekord z bazy na obiekt. 1000 obiektów to się nie dziwię, że mogło coś nawalić. a jeżeli masz 10, 20 (stronicowanie) rekordów wyświetlanych na stronie to nie ma z tym problemu.
w przypadku, który opisałeś trzeba ominąć obiekty i zwracać tablicę. tak pisali w symfony.

To się w 100% zgadza. Bez względu na ORM hydrowanie obiektów przy dużych ilościach rekordów będzie wymagające zarówno czasowo jak i pamięciowo.
Tylko używanie tablic troszke mija się z całym założeniem ORM'a.

Np. na filmdnia.pl wszystko to obiekty i też per strona jest ich całkiem sporo: kategokie, kanały telewizyjne, połączenie kanał-data emisji, aktorzy, reżyserzy. To wszystko raz kilkadziesiąt filmów per strona.
I wszystko ładnie na obiektach śmiga w propelu i zjada maks 5MB i wykonanie strony na poziomie 50-100ms więc tragedii nie ma.

A teraz, gdybym chciał to przerobić na doctrine, to musze się liczyć ze znaczym wzrostem zużycia pamięci jak bardzo dużym wzrostem czasu wykonania (patrząc na ten japoński test test).

Tak jak pisał Wojtek: albo wydajność, albo prostota kodowania :)
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: doctrine vs propel

Aleksander Wons:
Od 200 do ponad 1000 rekordów z bazy per strona (samych zapytań niewiele).
Tutaj nawet optymalizacja, cache i eaccelerator niewiele pomagał, bo userzy często dostawali white screen.

bez obrazy, ale to mi od razu zalatuje na jakiś błąd logiczny, po co 1000 rekordów na raz?
Link do wypowiedziLink

konto usunięte

Temat: doctrine vs propel

Wojciech Sznapka:

bez obrazy, ale to mi od razu zalatuje na jakiś błąd logiczny, po co 1000 rekordów na raz?

3 type wyścigów w jednej kategorii. Powiedzmy, że po 25 zawodników na typ. W sezonie mamy np. 10 wyścigów. Do tego dochodzi info o najlepszym czasie okrążenia dla zawodnika w danym wyscigu. I jeszcze musimy pobrać info o klubie zawodnika, a ten co sezon może jeździć w innym klubie.

Ja też nie sądziłem, że to może tak wyglądać, ale niestety nie da się tego za bardzo przeskoczyć. Można by to nieco zoptymalizować, ale też moim zadaniem było tylko dokończyć tak, żeby działało zgodnie z życzeniem klienta.
Gdybym miał to przerabiać to na 100% zrobiłbym to inaczej niz jest. Ale to i tak nie zmienia faktu, że danych do wyciągnięcia jest po prostu dużo.
Link do wypowiedziLink
Adam W.

Adam W. senior php
developer, Symfony

Temat: doctrine vs propel

Aleksander Wons:
To się w 100% zgadza. Bez względu na ORM hydrowanie obiektów przy dużych ilościach rekordów będzie wymagające zarówno czasowo jak i pamięciowo.
Tylko używanie tablic troszke mija się z całym założeniem ORM'a.

też mnie to zdziwiło jak pisali na stronach symfony żeby tablice wypluwać.
Np. na filmdnia.pl wszystko to obiekty i też per strona jest ich całkiem sporo: kategokie, kanały telewizyjne, połączenie kanał-data emisji, aktorzy, reżyserzy. To wszystko raz kilkadziesiąt filmów per strona.
I wszystko ładnie na obiektach śmiga w propelu i zjada maks 5MB i wykonanie strony na poziomie 50-100ms więc tragedii nie ma.

A teraz, gdybym chciał to przerobić na doctrine, to musze się liczyć ze znaczym wzrostem zużycia pamięci jak bardzo dużym wzrostem czasu wykonania (patrząc na ten japoński test test).

Tak jak pisał Wojtek: albo wydajność, albo prostota kodowania :)

ano tak. ale zastanawiam się dlaczego w propelu można a w doctrine już nie. mam nadzieję, że w następnej wersji zrobią tak, żeby była prostota używania i szybkość działania.
Link do wypowiedziLink

konto usunięte

Temat: doctrine vs propel

Adam W.:

ano tak. ale zastanawiam się dlaczego w propelu można a w doctrine już nie. mam nadzieję, że w następnej wersji zrobią tak, żeby była prostota używania i szybkość działania.

Przyznam się bez bicia, że nigdy nie przyglądałem się hydracji obiektów w doctrine i nie mam pojęcia dlaczego są aż tak ogromne różnice. Poza tym chyba w teście widać, że nawet zwracanie tablicy jest o wiele szybsze w propelu niż w doctrine (bez cache'y w doctrine). Więc chyba problem jest gdzie indziej.

Ja liczę na to, że wraz z wersją 2.0 doctrine już będzie o niebo lepsze, bo rzeczywiście wygoda użytkowania jest niebo lepsza niż w propelu.
Link do wypowiedziLink

konto usunięte

Temat: doctrine vs propel

Zobaczymy co też przyniesie Propel 2.0 Tylko ciekawe kiedy się pojawi. Wersja 1.4 wniosła parę fajnych rzeczy, z czego cieszę się niezmiernie.
Link do wypowiedziLink
Tomasz Ducin

Tomasz Ducin System Designer &
Architect, Trainer

Temat: doctrine vs propel

Adam W.:
Aleksander Wons:
To się w 100% zgadza. Bez względu na ORM hydrowanie obiektów przy dużych ilościach rekordów będzie wymagające zarówno czasowo jak i pamięciowo.
Tylko używanie tablic troszke mija się z całym założeniem ORM'a.

też mnie to zdziwiło jak pisali na stronach symfony żeby tablice wypluwać.

A mnie nie dziwi. Owszem, po to jest ORM, żeby sobie ułatwiać i pisać metody dla klas modelu (kiedy się używa hydrate), ale nie musi tak być zawsze.

Tworzenie obiektów jest czasochłonne. Nie zawsze de facto obiekty są potrzebne. Doctrine + symfonowe API daje możliwość pisać zapytania DQLowe przejrzyście i dopiero na samym końcu zdecydować czy ->execute() czy ->fetch(). I nie chcę powiedzieć że hydrowanie jest złe, tylko nie w 100% jest potrzebne (żeby było jasne).

Nie widzę powodu dla którego mieliby odebrać tę możliwość - każdy wybiera co mu w danej chwili jest potrzebne.

A co do dyskusji - przyznaję szczerze - nie robiłem testów wydajnościowych, bo trzeba by naprawdę się do takich przyłożyć - ale pod względem wygody użytkowania to zdecydowanie - jak większość - Doctrine :).Tomasz Ducin edytował(a) ten post dnia 07.12.09 o godzinie 17:09
Link do wypowiedziLink

konto usunięte

Temat: doctrine vs propel

Wojciech Sznapka:
Krzysztof Staniszewski:
Przemysław Ciąćka:
A mnie, np. ostatnio Doctrine zawiódł trochę gdy chciałem go wykorzystać przy projekcie z PostgreSQL, używając przy tym Symfony 1.2.5.
Ma problemy z wygenerowaniem schematu z gotowej bazy, w której występują relacje pomiędzy tabelami.

Mimo wszystko w używaniu z MySQL jak najbardziej Doctrine.

Docrtin + postgres = nie rob tego ;) sporo sie chlopaki pochwalili, czego to tam nie ma, a w kodzie zrodlowym niestety bida :) zeby nie powiedziec z nedza :) ogolnie to doctrine to jest chyba taki mysql orm :D a reszta to tylko propaganda...

A co nie działa? Ja używam Doctrine + Postgres i póki co, poza warningami z doctrine:build-sql, na inne problemy nie natrafiłem.

wyszukiwanie z uzyciem gin i gist... w dokumentacji jest o tym powiedziane, ale w kodzie ani sladu... jak dla mnie to dosc spore niedopracowanie...
Link do wypowiedziLink
Szymon Kapturkiewicz

Szymon Kapturkiewicz CEO in InterSynergy
/ software architect

Temat: doctrine vs propel

Przygotowuję zespół do pracy przy dwóch bardzo dużych projektach, które będą prowadzone równolegle. Jak do tej pory nie miałem do czynienia z Doctrine. Tylko Propel od symfony w wersji 1.0. Można ponarzekać na bardzo mozolne pisanie kodu, ale powoli do tego już przywykłem...

Zastanawiam się nad tym co byście doradzali, czy warto się przesiadać na Doctrine przy tworzeniu serwisów o oglądalności ok. 5 000 000 page views miesięcznie?

Jakie są plusy, a jakie zalety?
Nie wspominając o wciąż ubogiej bibliotece pluginów dla doctrine.
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: doctrine vs propel

Szymon Kapturkiewicz:
Przygotowuję zespół do pracy przy dwóch bardzo dużych projektach, które będą prowadzone równolegle. Jak do tej pory nie miałem do czynienia z Doctrine. Tylko Propel od symfony w wersji 1.0. Można ponarzekać na bardzo mozolne pisanie kodu, ale powoli do tego już przywykłem...

Zastanawiam się nad tym co byście doradzali, czy warto się przesiadać na Doctrine przy tworzeniu serwisów o oglądalności ok. 5 000 000 page views miesięcznie?

Jakie są plusy, a jakie zalety?
Nie wspominając o wciąż ubogiej bibliotece pluginów dla doctrine.

przy takiej odwiedzalności zrobiłbym raczej doctrine dla backendu (panelu administracyjnych) a dla krytycznych elementów frontendu zapytania wprost przez PDO, chyba, że porządnie zaprojektujesz cache, co byłoby bardzo wskazane.

Co do plusów:
- DQL
- DQL
- DQL
- behaviory (również pisanie własnych)
- obsługa relacji (daleko wygodniejsza niż w propelu)
i inne, których teraz ciężko mi sobie przypomnieć. W każdym bądź razie, ile razy siadam do projektu w Propelu to mi zawsze czegoś brakuje, co jest w doctrine.

btw. co rozumiesz pod pojęciem "uboga biblioteka pluginów"? Jakich konkretnie brakuje?Wojciech Sznapka edytował(a) ten post dnia 10.12.09 o godzinie 08:35
Link do wypowiedziLink
Radek Baczyński

Radek Baczyński GoldenLine.pl

Temat: doctrine vs propel

Szymon Kapturkiewicz:
Przygotowuję zespół do pracy przy dwóch bardzo dużych projektach, które będą prowadzone równolegle. Jak do tej pory nie miałem do czynienia z Doctrine. Tylko Propel od symfony w wersji 1.0. Można ponarzekać na bardzo mozolne pisanie kodu, ale powoli do tego już przywykłem...

Zastanawiam się nad tym co byście doradzali, czy warto się przesiadać na Doctrine przy tworzeniu serwisów o oglądalności ok. 5 000 000 page views miesięcznie?

Jakie są plusy, a jakie zalety?
Nie wspominając o wciąż ubogiej bibliotece pluginów dla doctrine.


5M PV to już całkiem fajnie, ciekawe jak sobie poradzi sf, chociaż wiele zależy od serwera(ów). Polecam Doctrine+do tego plugin DbFinder, który pozwala łatwo i szybko robić zapytania do bazy bez hydratacji wyników(w czystym Doctrine też się da ale moim zdaniem DbFinder jest fajniejszy)
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: doctrine vs propel

symfony sobie imho poradzi. W razie czego dołoży maszynę, postawi memcache, przemyśli dobrze architekturę i będzie la la li :-)
nie pchałbym się w duży projekt bez symfony (yahoo bookmarks, dailymotion i inni chyba myślą podobnie)Wojciech Sznapka edytował(a) ten post dnia 10.12.09 o godzinie 09:25
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj