Witam,

mam pytanie czy macie jakieś obserwacje dotyczące wydajności symfony w dużych projektach. Konkretnie nurtuje mnie czy rozległość "w poziome" portalu wpływa znacząco na wydajność. Czyli przykładowo jeden projekt symfony obsługuje np. wortal + sklep + forum + katalog.
Wiadomo w takich przypadkach przyrasta klas, reguł w konfiguracji itp. Pytanie czy to znacząco negatywnie wpływa na wydajność. Nie mam jeszcze nic na czym mógłbym to porównać, więc chciałbym poznać wasze opinie/doświadczenia.

Żeby doprecyzować chodzi mi tu o to, że portal (a co za tym idzie pojedynczy request) nie tyle jest skomplikowany co rozległy.

Jeżeli poprawnie zaprojektujesz strukturę (baza, kod) to problemów nie będzie

W pewnym niewielkim stopniu tak, spada wydajność. Ja doszedłem w pewnym momencie to 10 MB konsumpcji pamięci, bo klasy propela mają nieprzyjemny zwyczaj rozrastania się za każdym razem, gdy skorzystamy z klucza obcego w innej tabeli. Tym samym np. klasa sfGuardUserProfile ma u mnie obecnie coś w okolicach 90KB i ~4000 lini kodu (z komentarzami), a jako że jest stosowana przez większość modułów, obniża wydajność w całkiem znaczący sposób. Co do konfiguracji, to nie widzę jakiegoś dużego problemu. Ile możesz mieć wpisów? 500? 600? Wątpię trochę.

Wystarczy jednak jakiś akcelerator, usunięcie komentarzy z modeli, "spakowanie" jądra Symfony i mamy timingi niziutkie i zużycie pamięcie na poziomie 2 MB

Pozdrawiam.

Czego używasz do "pakowania"? A czy przy akceleratorze jest sens usuwać komentarze z plików php? Bo przecież akcelerator przechowuje "skompilowaną" wersję skryptu, która nie zawiera formatowania/komentarzy. Przynajmiej tak mi się wydaje.

10 MB RAM? Nietrudno znaleźć CMSa, który po instalacji ciągnie kilkanaście i więcej na stronie głównej

Nie ukrywam, że właśnie propel budzi moje największe obawy - czasami klasy są tak przepakowane zbędnymi funkcjami, że aż strach ich używać...
BTW - zaciekawiłem się twoim stwierdzenim o akceleratorze - na swoim laptopie nie miałem zainstalowanego. Postawiłem sobie APC i zużycie pamięci spadło z 12M na 3,5M... Całkiem nieźle spodziewałem się spadku w granicach 40%.

Ciekawi mnie też co rozumiesz przez "spakowanie jądra", bo właśnie szukam takich "przyspieszaczy".

Więc może doctrine? Tam klasy są tak proste, że nawet można je samemu pisać z palca.

Przymierzam się, acz poza wydajnością propel spełnia wszystkie moje oczekiwania. Z tego co wiem (bardziej ze słyszenia niż praktyki) to jednak doctrine jest uboższe. Dlatego najpierw przyjrzę się nowej wersji propela, która korzysta z PDO a potem doctrine jeśli czas pozwoli. Do doctrine się przymierzam bo pewnie jest znacznie bardziej wydajne niż propel.

Tymniemniej w tej chwili kończę projekt, które bazuje na propelu i to już się raczej nie zmieni bo zbyt wiele zachodu kosztowałoby przepisanie tego wszystkiego. Raczej będę próbował tutaj uzyskać jak najwyższą wydajność.

Mi się z kolei wydaje, że doctrine ma dużo większe możliwości. Choć nie znam na tyle ani jednego, ani drugiego rozwiązania, żeby móc to stwierdzić z pewnością. Być może to moje przeświadczenie wynika z tego, że doctrine ma dużo bardziej rozbudowaną dokumentacje, która opisuje jego możliwości. W propelu wygląda to dosyć słabo niestety.

LOL
"Niestety nie znam się na tym ale mi się wydaje ..." - blablabla
Jeśli chodzi o porównanie Propela z Doctrinem to możliwości są podobne z choć ze wskazaniem na Propela jako bardziej funkcjonalny ORM.
W kwestii szybkości jest już bardziej jednoznacznie. Doctrine jest szybszy. Od Propela w wersji 1.2 natomiast Propel 1.3 bije na głowę Doctine'a. Co przy podobnych możliwościach dyskwalifikuje Doctrine'a.

http://www.symfony-project.org/book/1_0/18-Performance
Pod koniec tekstu od śródtytułu "Core Compilation" - tam jest o pakowaniu jadra, jak i dopakowywaniu swoich klas

Pozdrawiam

Proponuję przeczytać dokładnie i ze zrozumieniem to, co napisałem, a nie przypisywać mi stwierdzień, których nie użyłem.



Możesz rozwinąć swoją wypowiedź? Co ma propel bardziej funkcjonalnego? I na jakiej podstawie twierdzisz, że propel 1.3 bije na głowę doctrina pod względem wydajności?

Edit:

Przykład, czego brakuje w propelu to możliwości złączenia jednej tabeli wiele razy (po różnych kolumnach) do innej, tej samej tabeli. W doctrinie jest to możliwe dzięki aliasom w dqlu. Natomiast w propelu ma to być dopiero zaimplementowane w wersji 2.0, co pewnie szybko nie nastąpi sądząc po częstotliwości commitów do repozytorium w ostatnim czasie.

Stupid me... Jakoś już chyba zatraciłem umiejętność czytania ze zrozumieniem - nie dalej jak 2 tygodnie temu czytałem ten rozdział... Dzięki wielkie, muszę przejrzeć mój projekt i na pewno wyłowię kilka problematycznych klas.

co do predkosci ormow np http://phplightorm.wiki.sourceforge.net/Li...trine+benchmark wystarczy pogooglac troche, widziałem rownież kiedy test propela 1.2 1.3 (beta) i doctrine, ale znaleźć nie moge. Po krotce był ow nim że propel 1.2 wypadał b. biednie, 1.3 super, a doctrine pośrodku

Właśnie na to samo patrzyłem Faktycznie, widać, że doctrine ma większy narzut niż propel. Chociaż porównują wersję doctrine 0.10.2, a od tego czasu trochę więcej wersji się pojawiło.

Ale czy taki test syntetyczny jest miarodajny? Przy prostych operacjach może propel jest faktycznie szybszy, ale nie wiadomo, jakby to wyglądało przy bardziej skomplikowanych selectach, z wieloma joinami, rozbudowanymi warunkami (gdzie proces budowania sqla i wydobywania danych do obiektów jest bardziej skomplikowany).

Również przy insertach do tabel z triggerami, dużą liczbą indeksów przewaga propela może już nie być taka zauważalna, bo wąskim gardłem może stać się baza danych.

Skoro temat już poszedł w stronę porównywania ORM-ów, to powiem od siebie, że używałem i Propela i Doctrine i ten drugi wydał mi się o wiele bardziej przystępny. Najkrócej rzecz ujmując - to co przy pomocy obiektu Criteria w Propelu robimy w n liniach w Doctrine robimy DQL-em w jednej linii.

Propel w wersji 1.3 też nastawia sięmocno na fluent interface i też mozna psiać w jednej linii za pomocą Criteria.
Choć fakt DQL jest fajny, choć ja nie mogę z nim pracować. Za bardzo porównuje do HQL'a.

Tym samym Propel zbliża się do Hibernate-a. I dobrze - oby było wygodniej.

czy ktos może pokazać jakiś duży projekt w symfony, gdzie w bazie jest okolo 50- 100 tabel, i jak to szybko chodzi, ja probowałem cos zrobić gdzie ilośc tabel w bazie około 100, i niestety to bardzo wolno chodzi, na symfony 1.0

http://www.cmsynazamowienie.pl/katalogmedyczny/web/front.php
czasami chodzi szybciej bo cache ustawiony, ale docelowo tak byc nie może,

przy okazji symfony 1.2 chyba znacznie szybciej bedzie chodziło niz 1.0 chociażby ze względu na propela 1.3, czy tak?
pozdrawiam

Z tego co wiem to Pytamy.pl zrobione jest w symfony (jesli nie zmienieli tego). Jednak 50 tabel to zapewne tam nie ma..

napisz jakie są czasy wykonywania. ile zapytań do bazy.
bo ten link nic nie daje - nie przekonamy się czy to wolno czy szybko działa.
mi bardzo wolno, ale tak samo wolno działają inne strony - tzn ściągają się dane.

OMFG... że oni cię z tego hostingu nie wyrzucili ;-) To nigdy nie będzie szybko chodzić. na tej stronie masz 92 zapytania do bazy (to o jakieś ~85 za dużo). BTW zabezpiecz ten projekt bo teraz znam nazwy i pola połowy twoich tabel ;-).

//edit
na podstronach masz po ~230 zapytań do bazy

ale czas tylko około 500ms, no i pamięć tylko 4MB.
od czego ta pamięć zależy?
mi zajmuje jakieś 7, a czasem nawet 11. widać, że ilość zapytań nie wpływa na nią.

edit
patrząc na zapytania do bazy, można powiedzieć, że mamy tu przykład źle zaprojektowanej aplikacji. a później się dziwić, że piszą o ociężałości symfony:)

o szit... Aczkolwiek! Przebiję Cię:
http://www.cmsynazamowienie.pl/katalogmedy...uktura/idstr/82
682 Zgroza!

Wracając jednak do tematu: ja aktualnie piszę sklep z wykrozystaniem Kohana. Może nic wielkiego, zapewnie 50 tabel nie będzie posiadało, jednak jestem w 100% przekonany, że całość będzie chodziła zdecydowanie szybciej niż odpowiednik napisany w Symfony. Im więcej używam Kohana, z im więcej elementów korzystam, tym więcej kocham (tak!) ten framework. Moim zdaniem możesz spokojnie postawić dowolnie duży system na tym frameworku. Polecam!

Czasy mi wychodził od 1250-5.000ms ale to o niczym nie świadczy bo nie wiadomo na czym to stoi.
Co do pamięci to kilka kwestii:
- 4mb to odpowiednik około 10-12mb na localhoscie przy założeniu, że hosting ma akcelerator a Ty nie masz. Jak obniżyć zużycie pamięci pisał Cysiaczek wyżej w tym poście.
- możesz obniżyć ilość pamięci wczytując mniej kodu (np. usuwając komentarze z propela w pliku propel.ini)

Sam się jednak zastanawiam jakie zużycie pamięci jest ok - mam za mało aplikacji do porównania, więc chętnie poznam opinię kogoś kto więcej popełnił w symfony.
Co do ilości zużytej pamięci vs ilość zapytań (czyli utworzonych obiektów) to imho ma to znaczenie, choć nigdy nie napisałem aplikacji, która ma ~600 zapytań - mam za słabego kompa ;-). Zauważ, że stronka jest prosta więc aż tak duże zużycie pamięci jest "nieuzasadnione". Ja mam teraz jedną podstronę, która zużywa 4mb z akceleratorem ale bez żadnej dodatkowej optymalizacji typu cachowanie/usuwanie komentarzy itp. Z tym tylko, że strona jest na prawdę "cieżka" - zawiera około ~30 bardzo skomplikowanych obiektów (złożenia wielu tabel). Samych zapytań jest około 8.

Co do "Kohanej" to nie znam, ale w CI programowało mi się baaaardzo przyjemnie - trudno jednak porównywać te dwa frameworki - zupełnie inna filozofia. Wydaje mi się, że symfony jest bardziej ociężałe ale z drugiej strony szybciej się w pisze kod (z naciskiem na wydaje mi się). W każdym z tych frameworków można jednak napisać aplikację z "przyzwoitą" prędkością.

Moje doświadczenie podpowiada, że jeżeli zachowamy podstawowe reguły przyzwoitości, rozsądnie korzystając z propela (czyli doSelectJoinWszystkoCoNamPotrzebne), napiszemy ładny i przejrzysty kod, to projekt na symfony będzię ciągnął spokojnie długo...

Jak będziemy mieli dużo userów to ustawiamy proste cacheowanie.

Jak będziemy mieli bardzo dużo userów to będzie nas stać na to żeby zatrudnić kogoś kto się wszystkim zajmie, a my będziemy mogli leżeć na plaży w honolulu ;-)

witam szanownych kolegów,

czytając posty dotyczące aplikacji "katalog medyczny" znalazłem informacje o ilości zapytań i braku zabezpieczeń. jak mierzycie ilość zapytań do bazy generowane przez strony w "nie waszych projektach" ?

i życzę wszystkim Wesołych Świąt, jako że dzisiaj Wigilia.

To akurat cecha Symfony. W Symfony jest środowisko developerskie, które pokazuje takie informacje jak ilość zapytań (i ich treść), zmienne środowiskowe, logi, czasy wykonania, zużytą pamięć itp. Przed publikacją projektu należy te środowiska zdezaktywować czego kolega nie zrobił więc widzieliśmy te wszystkie informacje.

po co dezaktywować? to jest przydatne nawet na serwerze publicznym. wystarczy zmienić nazwę na trochę bardziej trudniejszą.
chyba że czegoś nie wiem?

Ja akurat preferuję usunięcie plików (nawet w cli jest odpowiednia komenda do tego) i dogrywanie ich w razie potrzeby - nie podobają mi się rozwiązania typu zmiana nazwy na trudniejszą. Ale każdy ma swoją "filozofię" i na pewno zmiana nazwy też zadziała w oczekiwany sposób.

dzięki,

teraz rozumiem o czym mówiliście, że kolega miał niezabezpieczoną stronę. wszystko jasne.

poprawka: dalej ma niezabezpieczoną

a dlaczego nie podoba Ci się ta "filozofia"?
wg mnie to żadna filozofia:) tylko po prostu zabezpieczenie przed informowaniem o tym co daje konfiguracja dev użytkowników, którzy nie muszą tego wiedzieć.
jakby tak za każdym razem wysyłać ten plik to można by się zamęczyć. jeżeli zmiana nazwy to dla Ciebie za mało to można zrobić dostęp na hasło. po podaniu hasła zapisywane dane w ciastku lub sesji i pasek dev pokazywany w ciągu całej sesji.

A dlaczego nie zabezpieczasz panelu administracyjnego zmieniając nazwę skryptu na jakąś trudną... Po prostu nie są to eleganckie rozwiązania. Sami developerzy symfony zalecają usunięcie "devów" z aplikacji.
Co do zabezpieczenia hasłem to jak najbardziej ok. Ale usuwanie z produkcyjnego serwera środowiska developerskiego nie jest jakieś strasznie problematyczne - w końcu to 1-2 pliki.
Zauważ, że dev niesie ze sobą bardzo poważne zagrożenie - jeśli do takiego pliku jakimś cudem dotrze googlebot (a wystarczy 1 niepatrzenie pozostawiony link) to cała strona będzie indeksowała się podwójnie a to już krótka droga do jakiegoś filtra za podwojenie treści. Więc ogólnie zabezpieczanie hasłem ok, ale zmiana nazwy pliku to jak dla mnie takie brzydkie i niebezpieczne rozwiązanie.

Od wersji 1.1 kontrolery środowiska deweloperskiego dostają dodatkowe zabezpieczenie w postaci sprawdzania adresu IP ($_SERVER['REMOTE_ADDR']). Standardowo jest tam 127.0.0.1, ale można dodać też własne zewnętrzne IP. Plik będzie na serwerze a dostęp zabezpieczony. Chyba, że da się obejść.

sugerujesz ze ktos moglby na glownej stronie wersji prod podac link do wersji dev? to by dopiero bylo niebezpieczne. jezeli ktos tak robi to rzeczywiscie lepiej usunac te pliki,



nic nie stoi na przeszkodzie zeby zaimplementowac to w wersji wczesniejszej:)

A dlaczego zaraz na głównej? Zawsze jakiś link może Ci się zapodziać/wyciec. A to wkleisz przez przypadek na forum, a to omyłkowo dodasz do delicious zamiast zwykłej perspektywy, a to podasz klientowi który nie odróżnia jednej perspektywy od drugiej i gdzieś to wrzuci, a to zrobisz sobie linka na stronie dla szybkich testów i potem nie usuniesz, a to awaria zaskoczy cię gdy nie będziesz miał swojego kompa - sprawdzisz coś na cudzym i nie usuniesz historii itd itp... wiele się może zdarzyć.

Ostatnio testowałem wyszukiwarkę, która sama indeksowała strony biegając po linkach... Jakie było moje zdziwienie gdy w wynikach wyszukiwania znalazłem strony admina (nie były jeszcze zabezpieczone hasłem bo projekt na localhost)... Winny był właśnie jakiś link wstawiony na szybko dla testów - takie rzeczy na prawdę łatwo przeoczyć.

Także pytanie brzmi - czy zostawiłbyś panel admina do poważnego projektu z zabezpieczeniem polegającym na nietypowej nazwie? Pewni nie... Na tej samej zasadzie nie zostawiam perspektywy developerskiej. Wolę dmuchać na zimne. Jeśli Ty robisz inaczej Twoja sprawa - ale takie zabezpieczenie to żadne zabezpieczenie.

Wydaje mi się, że wystarczy po prostu "wyłączać" środowisko developerskie. Usuwać to za dużo, czasem przydaje się testowanie na serwerze. Zmiana nazwy + nałożenie na odp. IP + wyłączanie aplikacji ( tu pomaga opcja disable dostępna w Symfony ).