[Symfony]Symfony a duże projekty, wydajność Opcje

[AxZx]

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

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.

[athabus]

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

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

Ten post edytował athabus 7.12.2008, 20:45:12

[AxZx]

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:)

Ten post edytował AxZx 7.12.2008, 21:01:33

[phpion]

na tej stronie masz 92 zapytania do bazy (to o jakieś ~85 za dużo)

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

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!

[athabus]

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ą.

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ą.

[sneq]

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 ;-)

[misiaczekmarek]

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.

[athabus]

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.

[AxZx]

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?

[athabus]

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.

[misiaczekmarek]

dzięki,

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

poprawka: dalej ma niezabezpieczoną

Ten post edytował misiaczekmarek 25.12.2008, 12:00:07

[AxZx]

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.

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.

[athabus]

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.

[destroyerr]

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ść.

[AxZx]

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.

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,

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ść.

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

[athabus]

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,

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.

[c3zi]

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 ).