Trudno jest jednoznacznie ocenic czym jest 'w miare duzy projekt', ale mysle ze wspolnym mianownikiem dla takowych jest brak mozliwosci skorzystania z gotowych rozwiazan bez ich modyfikacji. Wiekszosc frameworkow jest pisana pod malej/sredniej wielkosci serwisy: blogi i przegladarki bazy danych. Duze projekty maja to do siebie, ze podczas ich pisania wychodza zupelnie nieprzewidywalne problemy wydajnosciowe (np. powolnosc __autoload) i wtedy trzeba usiasc i zmienic implementacje na lepsza dla specyficznych wymagan projektu. Przywiazanie do frameworka w takiej sytuacji moze bolec. Trzeba moc powiedziec 'stop', odpiac sie od drzewa rozwojowego frameworka i zrobic jego wyspecjalizowana wersje.

Sama wydajnosc jest zwodnicza. Programista zawsze chcialby, zeby wszystko bylo ladnie i szybko, ale ilu z Was zastanawialo sie co o tym mysli klient? Niektore zapytania raportowe zawsze beda trwaly kilka godzin, a czasami klient korzystajacy z aplikacji siedzi po drugiej stronie oceanu i jest mu zupelnie obojetnie czy serwis reaguje w 5ms czy w 100ms, bo u siebie i tak ma to z 200ms opoznienia. Nie odgaduj wymagan klienta, sam ci powie czego oczekuje.

Piszac duzy system musisz byc elastyczny, scisle trzymanie sie frameworkow zmniejsza elastycznosc.

Rozmowa o frameworkach zawsze stanowi pewien problem, tak jak i wymagania zawsze są inne.

Wydaje mi się więc, że jedyne rozwiązania które mogą się sprawdzić w różnorakich zastosowaniach i nie stanowić zbyt dużego obciążenia dla wydajności do zestawy klas typu EZ compontents albo ZF - dobrze przemyślane mechanizmy realizujące konkretne zadania w szybki i skuteczny sposób.
Są to jedyne 'frameworki' które uznaję, bo w ich przypadku nie mam cały czas wrażenia, ze 'za chwilę' okaże się, że wykorzystywany przeze mnie szkielet nie będzie wstanie czegoś zrobić. W przypadku wykorzystywania ZF oznaczać to może po prostu, że należy coś inaczej zestawić, wykorzystać inny komponent, lub po prostu coś dopisać.

Oczywiście narzędzia typu Prado albo Symfony również mogą się wielu ludziom przydać, szczególnie w przypadku braku własnych narzędzi i sprawdzonych rozwiązań, jednak ich użyteczność jest znacznie mocniej ograniczona.

Jeśli porównując Symfony do ZF mówisz że Symfony jest przy nim ograniczone to nie masz zielonego pojęcia o czym mówisz.
Najzwyklej nie znasz Symfony.

mike_mech - myślę jednak, że tym razem nie przeczytałeś ze zrozumieniem.

Symfony jest bardzo rozbudowaną aplikacją, w bardzo zaawansowany sposób wspierająca programistę. I ja dobrze sobie z tego zdaję sprawę, choć osobiście nie przepadam za tego typu rozwiązaniami.

Z przekonaniem będę jednak bronił stanowiska, że:
1) narzędzia typu ZF czy eZComponents można zastosować w o wiele większej ilości przypadków - są bardziej elastyczne i pozwalają na bardziej "wybiórcze" wykorzystanie
2) zarówno Symfony jak i PRADO - mimo bardzo rozbudowanych systemów cache i sporej optymalizacji kodu - narzucają spory bagaż na wydajność aplikacji. W takim przypadku chęć optymalizacji pewnych elementów, ich uproszczenie lub 'rozczłonkowanie' może być na tyle trudne, że łatwiej byłoby pewnie napisanie tych elementów od zera.

A w Symfony osobiście nie lubię nadmiernego pracowania "za" programistę i oraz wykorzystywanie XML'owego DAO, choć wiem, że to akurat można ominąć.

@Turgon - a Twoja wypowiedź jak zawsze - ma bardzo dużo sensu. Żeby choć była gramatyczna... (kurcze - tylko nie tłumacz się potem, że znów byłeś chory)

To że symfony jest wolne i krowiaste to niestety fakt. Ale ze sie wygodnie na nim pracuje to co innego , chociaż brakuje pare rzeczy

ZF może da się użyć w dużej ilości wypadków, ale trzeba jeszcze dużego nakładu pracy aby powiązać to w miarę sprawnie. I właśnie na tym polu Symfony wygrywa, gdyż rozwiązanie zostało sprawdzone wielokrotnie, a do ZF trzeba obsluge podstawowych czynności dopisać (odpalanie akcji, filtow etc) a jak praktyka wielokrotnie dowiodła rozwiązania dopiero co wprowadzone w 99% będą wolniejsze.


1) Czy duża biblioteka znaczy, że rzecz jest krowiasta? Jakiś konkretny dowód masz odnośnie Symfony?
2) Czego brakuje?

A ja będę dalej dawać za przykład tego, że Symfony nie jest krowiaste i nieelastyczne Yahoo Bookmarks

Jak już o frameworkach mowa: czy w php są jakieś LEKKIE frameworki do budowy aplikacji?
Przez lekki rozumiem framework, który nie narzuca określonego sposobu pisania kodu - możesz wziąć z frameworka tylko tyle ile chcesz, a reszty swojego kodu nie musisz do tego dostosowywać.
Przykładem lekkich frameworków dla Javy jest SPRING. Mozna pisać kod w Springu, który jest 100% czystym kodem Javy bez używania jakichkolwiek importów ze Springa.

I drugie pytanie:
Czy jest dla php jakiś framework wspierający IoC? IoC bardzo ułatwia tworzenie i testowanie dużych projektów.

CodeIgniter albo ZendFramework przy czym chyba ZF by ci bardziej spasował skoro chcesz poszczególne klasy sklecić wg. własnego 'widzimisie'.

Witam,

jako że jestem autorem wątku, postaram się odnieść do wypowiedzi powyżej i tego na co ostatecznie postawiliśmy:

Symfony Framework - za jego wydajność, skalowalność, szybkość kodowania, dokumentację, wsparcie, wydajność, wydajność, wydajność, szybkość kodowania, wsparcie, dokumentację, wydajność...

MySQL w wersji 5.1.x obsługiwany za pomocą ORM'a - pewnie za raz padną teksty, że nie ma to prawa bytu, a ja na to jak na lato - bo to działa bez zarzutu - co ciekawe nie jestem jedyny, na grupach Symfony pojawiły się posty w których to autor prezentował wyniki działania aplikacji opartej o Symofny mającej ponad 25, a może i 35 mln rekordów w bazie danych. Wszystko to stoi na 2 serwerach (jeden do obsługi ruchu WWW, a drugi do obsługi serwera baz danych - MySQL.

Od kilku miesięcy cała moja firma, a tym samym programiście w niej pracujący kodują większość rozwiązań PHP'owych właśnie w oparciu o Symfony. Klienci są zadowoleni z wydajności pracy, ja z kasy, serwery z małej ilości pracy przy dobrej konfiguracji środowiska produkcyjnego.

Dodam że dziś wyszła stabilna wersja 1.0 Symfony, niedawno opublikowana została książka - za darmo dostępna na stronach projektu, a np. takie dodatki jak obiekt $browser (odsyłam do dokumentacji) do testowania wydajności aplikacji mówią mi że jako kierownik projektów postawiłem na dobre rozwiązanie.

Co do innych rozwiązań, jak ZF czy EZ Components - można wybiórczo użyć w Symfony, albo napisać sobie plugin, ehhh po co pisać pewnie już jest napisany .

Pozdrawiam, anas

Wbrew pozorom, symfony nie jest najwolniejsze. Z moich testów, które przeprowadziłem przy pomocy XDebuga wynika, że było szybsze niż Agavi (+Smarty).

true, smarty przymuli wszystkim

http://www.alrond.com/en/2007/jan/25/perfo...ing-frameworks/
http://wiki.rubyonrails.com/rails/pages/Fr...k%20Performance
http://www.sellersrank.com/php/cakephp-cod...iter-benchmark/ (+symfony)

oczywiście zawsze można mieć jakieś "ale" odnośnie metodologii badań ale wiecznie ostatnie miejsca okupowane przez Symfony chyba nie plasują tego FW w kategoriach "wydajny"?

"Hehe" potęguje tylko fakt, że podpierasz się opiniami innych, a nie swoim doświadczeniem - testowałem różne rozwiązania, testowałem rozwiązania własne, oceniałem je na tle kosztów utrzymania, rozwoju...

Ja mogę napisać skrypt, który nazwę HyperFastPHPFW, który będzie po prostu realizował wyświetlenie Hello World i nie zapewniał nic dodatkowego - wygram we wszystkich testach, pytanie co z tego. Symfony dostarcza mnóstwo narzędzi, które usprawniają pracę, wydajność(cache po stronie templatów, cache po stronie dostępu do danych). Tak naprawdę fakt czy dany framework jest dobry czy nie, wydajny czy też nie - nie określa głupi (bo inaczej go nie nazwę) test wyświetlania HelloWorld, a składowa wielu czynników o których zapomniałeś.

Osobiście nie zależy mi na tym aby ktokolwiek wierzył, czy nie wierzył w to co piszę - Polacy to uparty naród - ale Symfony jest wydajnym frameworkiem, tylko trzeba go odpowiednio dostroić.

Pozdrówka, anas

Edyta:

Tak BTW, to warto poczytać wyniki różnych innych testów - mimo, że nie odnosiłbym się jak pisałem powyżej z pełnym zaufaniem, bo są "debilnie" nierealne, ale poniżej dowód na to, że Symfony nie wypada aż tak źle - bo z 4 testowanych FW, jest tutaj drugim pod względem wydajności, przy założeniu że ma największą ilość załadowanych dodatków(plików) - dając tym samym dużo większe możliwości.

Oto adres: http://paul-m-jones.com/blog/?p=236

Czytanie ze zrozumieniem to chyba kolejny problem naszego narodu, cóż.

Pierwsza rzecz to przelewanie na wpisy w ramach blogu - gdzie, ktokolwiek wspominał, że masz to robić - podkreślam, bazujesz na opiniach z blogów, przytaczasz argumenty innych - napisz: pracowałem na: X, Y, Z - w mojej ocenie Y wypada najlepiej bo... i jeśli przekonasz mnie, moich klientów, programistów, administratorów że inny framework jest korzystniejszy, podbudowując to konstruktywną argumentacją, uwierz mi że będę się mocno zastanawiał nad ewentualną zmianą.

Porównanie do Hammer'a jest ni w ząb nie trafione, bo moja "Edyta" wyraźnie wskazała, że nie masz racji, nawet co do testów na których bazujesz. Są inne, całkiem odwrotne do tych które podałeś. Ja dodatkowo mogę powiedzieć co nieco prosto z warsztatu, bo moja firma jak wspominałem bazuje na Symfony, jeśli chodzi o aplikacje PHP.

Porównując Symfony do np. takich FW jak ZEND FW, Solar - to tak jak bym porównywał .net + VS Studio, do EditPlus'a i korzystania z MFC. Dzisiejsze koszty sprzętu w stosunku do kosztów pracy inżynierów są śmieszne. Skoro optymalizacja wydajność, bazująca na pracy 3-4 inżynierów to koszt średnio 12-15 tyś miesięcznie na rękę + ZUS, podatki, koszta utrzymania firmy, to ja za te pieniędzy dozbroję się w kolejny serwer i wydajność zostanie podniesiona dużo bardziej. Dodatkowo optymalizując środowisko pracy, można zbliżyć się do wyników najbardziej wydajnych środowisk, który przytaczałeś.

Dodam jeszcze, że w stosunku do inżynierów Yahoo, Twój autorytet ma dla mnie mniejszą wagę, a oni postawili właśnie na Symfony, przy jednym z serwisów tematycznych i co ważniejsze, są z tej decyzji zadowoleni. Niemniej jednak każda konstruktywna wypowiedź ma wartość merytoryczną, byleby właśnie była konstruktywna.

Każdy robi to co lubi, jeśli nie lubisz Symfony to używaj innych narzędzi, jeśli jednak nie masz pewności polecam wypróbować - to nic nie kosztuje poza poświęconym czasem.

Pozdrówka, anas

Edyta: No i bym był zapomniał - porównujemy FW bazujące na 4 i 5 wersji PHP - to też silny argument który wpływa na decyzję - zalet programowania obiektowego nie trzeba chyba nikomu tłumaczyć, ograniczeń co do tych kwestii 4 wersji PHP też, nie będę wspominał o tym że warto zastanowić się nad dostępnością php4 w stosunku do php5 teraz i za kilka lat, chyba że myślimy o aplikacji na dzisiaj i wczoraj, nie dzisiaj i jutro.

Wydzieliłem z tematu parę "bardziej osobistych" postów.
Szkoda psuć ciekawy wątek. - DeyV

PHP4 to przezytek - czy jest na serwerach czy nie. I to jest pewne.

Duze projekty przewaznie chodza na serwerach dedykowanych badz firmowych - bo duzego projektu na hostingu wspoldzielonym to ja nie widze. Dlatego tez jedyne sensowne PHP w duzych projektach to PHP5 i basta.

Co do testowania - zadnego z testow nie uwazam za wiarygodne - sporo z nich przegladam ( linkow nie pamietam ) i przewaznie sie rozne wyniki.

Z tego co ja przejadlem pomimo mojego mlodego wieku wynika iz miejscami dobrze napisac FW pod konkrenty projekt. Mowie tu o obciazeniu rzedu kilku mln uniq Napisanie fw pod taki projekt do dla dobrego programisty nie jest niczym szczegolnym. Kierujac firmowym FW wycina sie to co zbedne. Np. jakies pluginy kontrollera ( ZF ) na rzecz konkretyzacji np. pluginu autoryzacyjnego.

ORM - korzystalem tylko z phpDoctrine. Propela chcialem raz uzyc z grubej dosc rury pt. 70 kilka tabeli. Pojawialy sie joiny po kilkunastu tabelach i nie chcialo mi sie patrzec na wydajnosc tego bo jej nie bylo. SMARTY do tego i byl kill. Ale Propela wywalilem przechodzac czesciowo na phpDoctrine, czesciowo na proste mapowanie klasami tabel i pojedynczych wierszy ( activeRecord itp ), do tego szablony przeszly na PHP i cud miod malina

Cześć!

Tak sobie czytałem ten topic i nasuną mi się pomysł jak można odrobinę "ztiuningować" serwis.
Wszyscy zapewne kojarzycie technologie AJAX z serwisami web 2.0 gdzie głownie jest wykorzystywana dla bajeru, po to aby użytkownikowi przyjemniej się chodziło po portalu.
Ale można tez wykorzystać AJAX-a to poprawy wydajności serwisu.

W "normalnych" okolicznościach to surfowanie po portalu wygląda następująco: użytkownik wchodzi na stronę, strona się ściąga, użytkownik klika jakiś link, i kolejna strona się ściąga, aż mu się znudzi i wyjdzie. W tej sytuacji można skorzystać z AJAX-a następująco: użytkownik wchodzi na stronę, strona się ściąga, użytkownik klika w jakiś link, i ściąga się tylko pewna część strony, a inne elementy pozostają nie zmienne. W tym przypadku przyjmijmy ze strona ma rozmiar 50 KB a użytkownik klika w 10 linków zanim mu się nie znudzi.

Wiec jest tak:
- 50 KB (pierwszy raz) + (50*10) = 550 KB
czyli serwer to każdego człowieczka wysyła ponad 0,5 MB

A przy wykorzystaniu tego co omówiłem przed chwilą, to wygląda tak:
- 50 KB (pierwszy raz) + (10*10) = 150 KB
czyli serwer wysyla tylko ~ 27% tego co by wyslal w tradycyjnych warunkach.
Czemu 10 KB a nie 50 KB? dlatego ze główne elementy które sporo waza takie jak reklamy, grafika, itd. pozostają niezmienne.

ps. Może ktoś mówić ze przeglądarki maja cache, ale według mnie to nie daje takich możliwości jak AJAX.

Pozdrawiam

a kiedy przychodzi do SEO to zbierasz resztki tego co z Ciebie zostanie po tym jak Cię klient dorwie i zaczynasz pisać wszsytko od nowa - AJAX w postaci zaproponowanej przez Ciebie TAK - ale dla panelu administracyjnego chyba, albo strony, która całkowicie pozycjonowanie olewa

Można to wszystko napisać tak, aby googlebot widział ten content. Po prostu każdy komponent piszesz w wersji AJAX i zwykłej A w serwisie wtedy możesz rozpoznać w jakiś sposób, czy np: Googlebot sobie chodzi i ustawić mu AJAX=false i po ptakach.

Tyle że to jest Cloaking czyli podstawianie botowi wyszukiwarki innej treści za co niestety Google potrafi ukarać.

Pozdrawiam

już tam nie przesadzajcie, jak wszystko trzeba używać z głową Ajaxa używać do takich elementów, których bot i tak nieindexuje (przykład: głosowanie w ajaxie, zamiast oddania głosu i reloadu strony) a nie do np. paginacji czy innych kluczowych elementów strony.

Poza tym jaki cloaking skoro każdy bot zobaczy to samo?

ewentualnie jedna wersja strony + funkcja JS, która zamieni linki z normalnych na "ajaxowe"

Zawsze lubiłem symfony, a zf jakoś mnie odrzucał.
Wczoraj poczytałem dokumentację tutorial przetłumaczony przez Wojtka Naruńca i naprawdę super rzecz. Byłem sceptycznie nastawiony do tego frameworka ale teraz jestem jego wielkim fanem.
Polecam wsystkim, dla których liczy się szybkość tworzenia, świetna dokumentacja oraz wsparcie

anas: twoj lobbing na rzecz symfony jest calkiem przekonywujacy , dlatego troche sie tym zainteresowalem
mam pytanie, jak wyglada tam sprawa z uzyciem szablonow xsl ? czy jest to wogole mozliwe ?

Hej,

a79rtur: a dlaczego miałoby nie być możliwe? Przecież to Open Source - można sobie przepisać framework w taki sposób aby była taka możliwość. Rozumiem, że chodzi Ci o jakąś automatyzacje, tak więc:

widok, to zwykły plik, więc możesz tam tworzyć XML'a który będzie opisywał Twój dokument, a następnie transformować go za pomocą XSL do np. XHTML'a - po stronie serwera można to usprawnić poprzez podmianę klasy

rendering_filter:
class: sfRenderingFilter

w pliku factories.yml

Oczywiście można też transformację przenieść na przeglądarkę, ale tutaj pojawia się wiele problemów z obsługą przez nie XSL'a.

Tak czy siak wszystko jest możliwe.

------------

BTW. Teraz borykam się z innym problemem - chodzi o wersjonowanie danych w bazie - wyobraźmy sobie sytuację, że produkt jest opisany za pomocą kilku tabel: produkty, atrybuty, atrybuty_produktow, zalaczniki_produktow, itd...

Teraz jakiś klient sklepu internetowego składa zamówienie dla produktu znajdującego się w jakimś stanie - jakaś cena, przypisane atrybuty, załączniki. Po złożeniu zamówienia dochodzi do tego że administrator kasuje załącznik i dodaje nowy, w drugim wprowadza zmiany (np. dotyczące gwarancji z 24 na 12 miesięcy). Zmienia wartość atrybutu "gwarancja" też z 24 na 12 msc, a tym samym wpływa to na cenę i w głównej tabeli produktu, więc i ją edytuje. Takich zmian dokonuje w między czasie wiele - użytkownik po 2 tygodniach loguje się na swoje konto i chce zobaczyć załącznik do produktu który zamówił (czyli stan taki jak z daty kiedy składał zamówienie) - podobnie ma widzieć odpowiednią cenę i atrybuty produktu.

Jak rozwiązujecie wersjonowanie danych na poziomie bazy, w systemach gdzie stan na daną datę jest krytyczny?

Pozdrówka, anas.

Troche to hardcore mowiac prawde W większości wypadków trzeba wesjonować wszystko - mowie np o calym rekordzie. Rozwiazanie z jakiego korzystam to pakowanie tar-em najczesciej i trzymanie wersji poszczegolnych w SQLLite - ew mozna to trzymac w plikach - obecna wersja w glownej bazie i tylko. Z takimi rzeczami jak atrybuty to by trzeba pomyslec - ale jakby sie chcialo do tego przylozyc to zapewne wypadaloby sobie napisac mechanizm drzewiasty bo on idealnie do czegos takiego sie nadaje : )

Jak się składa zamowienie na produkt - to sie powinno zgodnie z prawem dostac to co sie zamowilo - ale to taki maly OT: D

przykład z zamówieniem w sklepie internetowym:
dodałem dodatkową tabelę z zapisanymi zserializowanymi informacjami o produkcie (na wypadek gdyby mi jakieś pola doszły/uciekły) - klient zapisuje dane, a ja odczytuję - kiedy zamówienie zostanie zrealizowane rekord jest usuwany

PS. wszystkie zrealizowane zamówienia zrzucane są do osobnej tabeli a ta archiwizowana raz na miesiąc (umożliwia to odtworzenie wszelkich transakcji)

W sumie jak jest zmieniane coś więcej niż cena to już się staje innym produktem, bo zmieniając okres gwarancji tworzy się nowy produkt, najczęściej z inną ceną.
Edycja produktu powinna się ograniczyć do poprawy błędnych informacji, czy zmiany ceny (bo cena danego produktu maże się zmieniać, ale ją można trzymać w tabeli wiążącej transakcja-produkty)
A więc zmiana okresu gwarancji to utworzenie nowego artykułu, a stary staje się niedostępny do kupna.
Ale to są raczej moje rozmyślania, bo tabela produktów robi się przerostowa. A jak chcieć przenosić skasowane do innej to tabela wiążąca transakcja-produkt powinna wiedzieć, że produkt nie jest w aktywnej liście produktów, tylko w archiwum.
Np. mając dwie kolumny id jedna odnosi do aktualnej tabeli a druga do archiwalnej, tylko wtedy wyzwalacz który by przenosił produkt do archiwalnej przy kasacji musiał by też zmienić kolumnę z id... lub lepiej mieć dwie tabele wiążące transakcje z produktem

Co do przenoszenia (podkreślam, bo tworzenie kopi to inna sprawa) jakiś danych z bazy do pliku, jest dziwne, no chyba że to są elementy nie istniejącego już systemu, a dlaczego dziwne? Bo przecież wchodząc w swoje transakcje chcę widzieć wszystkie i móc zobaczyć co wtedy kupiłem, a nie że (np.) po pół roku znikają...
To przypomina mi Allegro gdzie jednaj osobie wystawiłem trzy razy komentarz, bo zmieniali system czy też archiwizowali(?), ale transakcja została, tylko informacja o komentarzu wyleciała...

Panowie, gdy sprawdzałem sobie wydajność frameworków to za głowę się złapałem. My piszemy kod na podstawie własnego framework'a, który za każdym razem obcinamy na potrzeby konkretnego projektu.

Ten sam kod po implementacji i benchmarkach:
Nasz FW: 300 req/s
ZF: 60 req/s
CakePHP: 27 req/s


Naszym zdaniem:
1. Zaoszczędzisz na czasie kodowania ($ dla programistów) = wydasz na infrastrukturę
(40k BRUTTO za m-c pracy zespołu to mały wydatek przy zakupie 10 wysokowydajnych serwerów)
2. Klient którego ktoś przekona że da się szybciej bez inwestowania w infrastrukturę nie zostawi u Ciebie po raz kolejny pieniędzy.

Bardzo to dobry i pożyteczny topic proszę wytłumaczyć laikowi tak w kilku zdaniach (bo wiem, że o frameworkach napisano juz wiele) co różni wymieniane frameworki i na jakie cechy kładzie się największy nacisk we własnych fw pod kątem aplikacji dużych i mocno obciążonych.
To nie jest pytanie z cyklu "który framework wybrać". Chciałbym się z grubsza dowiedzieć "co kosztem czego" w danym frameworku.

Panowie, ale wydaje mi sie, ze caly czas zapominamy o podstawowej rzeczy - o tworzeniu elastycznego i latwego w utrzymaniu kodu. Owszem, mozna napisac swoj FW (no dobra, biblioteke klas bo nowka sztuka FW to raczej nie bedzie) pod konkretna aplikacje. Mozna, ale potem project manager sie zmieni, lead programmer tez kiedys w koncu odejdzie skuszony praca dla JeszczeBardziejNowatorskiejFirmy i zostanie 2 swiezo przyjetych koderow, ktorzy beda probowali zrozumiec, o co chodzi w tym kodzie.

Ja wiem, upraszczam, ale zaleta stosowania najbardziej popularnych FW jest to, ze w razie jakichkolwiek zawirowan personalnych, dosc szybko mozna znalezc ludzi, ktorzy projekt pociagna dalej, bez tracenia miesiaca na rozgryzanie pozostalosci po poprzednikach. Zas nawet w samych popularnych FW da sie tak przykroic kod, ze zostanie tylko to, co konieczne - bezposrednie wpisywanie kodu SQL do zapytan, cache na wyniki zapytan do bazy, statyczny content, cache serwera lub samej bazy (memcache), uzywanie statycznego w znacznej mierze layoutu rozwiazuje kwestie wydajnosci w 90% przypadkow tzw. duzych projektow.

+1 dla @chlebika

To m.in. dlatego duże firmy wybierają Symfony.

Trochę rozbawiła mnie dyskusja na temat wyższości wydajności jednego frameworka PHP nad innymi
To trochę jak w czasach, kiedy szczytem marzeń był Polonez, porównywać czyj Fiat 126p wykręca więcej na liczniku.

A tak bardziej na serio, to:
1. Wiele serwisów przytyka się na bazie danych, nie na warstwie prezentacji / logiki biznesowej. I winny temu nie jest zwykle ORM, tylko po prostu brak umiejętności posługiwania się obecnymi RDBMSami. Np. jak ktoś robi złączenia kilkunastu tabel na MySQL, to tylko się prosi o kłopoty z wydajnością.

2. Tam gdzie wydajność wyższych warstw ma rzeczywiście ma znaczenie - lepiej pisać serwis w J2EE / .NET. Wydajność wykonywania kodu znacznie wyższa
(ponad 10x), lepsze biblioteki i frameworki, udogodnienia w języku specjalnie do dużych projektów (np. statyczna typizacja), narzędzia do refactoringu, większe możliwości buforowania różnych rzeczy, wiele gotowych zaawansowanych rozwiązań jak np. replikacja, failover itp. Wszystko to oczywiście da się uzyskać w PHP, ale robiliśmy kilka projektów w tym i w tym, i musze przyznać, że w J2EE wychodzi taniej szybciej i porządniej. Jedyny problem, że programiści J2EE cenią się zwykle wyżej niż PHPowcy, więc trzeba im więcej zapłacić. No i ostatnio coś ciężko ich na rynku znaleźć.

Co do porównania pehapowych FW to może i bym się zgodził, ale o jednej rzeczy zapomniałeś - o tym, że logikę też można skopać
Ba! Można ją skopać razem z bazą danych - wystarczy prosty skrypt w php wyświetlający dane z bazy w widoku przez mysql_fetch_assoc(), gdzie w pętli umieścimy dodatkowe obliczenia. Gwarantuję, że jeśli baza ma limity, to zdechnie .

W dużym serwisie łatwiej dostawić serwer z aplikacją niż kolejną bazę ( http://forum.php.pl/index.php?showtopic=10...st&p=515320 ). Jeśli łatwiej, to koszt utworzenia aplikacji w .NET, J2EE, czy PHP zdaje się nie mieć znaczenia. Różnice wydajnościowe muszą być niewielkie, skoro php jest dalej stosowane - te 10x to skąd wziąłeś? Bo to tak trochę jak z Rubym, który niby jest taki pro, a jednak muli i nikt go nie chce. Java też muli... .NET - nie wiem

Pozdrawiam.

1. Benchmarki: Wejdź sobie na Great Language Shootout. Ruby jest na końcu listy wydajności, PHP niewiele lepiej. Można instalować przyspieszacze (bytecode cache), ale i tak daleko jeszcze do szybkości języków z górnej części listy (C, C++, D, Java i parę innych).

2. Teoria: Język interpretowany, dynamicznie typowany (PHP, Ruby) zawsze będzie dużo wolniejszy od języka ze statyczną typizacją, natywnie kompilowanego (Java, .NET).

Mimo to, napisałem, że wydajność PHP na ogół nie jest przeszkodą, bo jak się dobrze napisze warstwę logiki / prezentacji, to ona niewiele ma do roboty w porównaniu z np. bazą danych. Oczywiście wszytko zależy od konkretnego systemu.

BTW: Dołożenie nowego serwera aplikacyjnego jest w PHP trudniejsze niż w J2EE. Choćby dlatego, że takie rzeczy jak replikacja przezroczysta dla aplikacji jest w J2EE dostępna "out of the box" (np. Terracotta) - instalacja w kilka minut i mamy klaster - z dowolnej aplikacji, bez ruszania ani jednej linii kodu źródłowego. Podobnie przy aplikacjach w EJB3 - przełączasz 2 switche w ustawieniach serwera aplikacyjnego i masz klaster. Tymczasem o PHP był tu gdzieś wątek i z tego co pamiętam, nikt nie podał satysfakcjonującego rozwiązania (replikacja sesji + failover).

J2EE Taaaak zajebisty pomysł pracuję właśnie w firmie zajmującą się tą technologią - pewnie dało się to zrobić lepiej, ale teraz projekt nad ktorym pracujemy jest ogromną kobyłą, która kompiluje się 12 minut, a uruchamia na serwerze kolejne 25min - najdrobniejsza nawet zmiana to ponad pol godziny czekania. Koledzy z .net mówią ze u nich jest podobnie Dlatego wole php - większość zmian wymaga tylko ctrl+r w przeglądarce i widzę efekty

mrok: Normalnie mało ze śmiechu się nie popłakałem. A nie można tego modułowo napisać i kompilować tylko konkretne części / biblioteki.
Poza tym chyba trochę przesadziłeś z tymi 25cioma minutami. Przecież to jest nierealne. To ta aplikacja służy do obliczeń danych z LHC.
Mógłbyś uściślić co to za kobyła która odpala się 25 minut ?

Dlatego taki framework można potem udostępnić np. na zasadach open source. Tak przecież zdobył popularność code igniter. Z drugiej strony nie wydaje mi się dużym problemem by zapoznać programistę w pierwszym miesiącu z wewnętrznym frameworkiem. Istotną kwestią jest to czy ten framework jest udokumentowany, dobrze napisany i ciągle rozwijany, jeśli tak to moim zdaniem śmiało w firmie można go używać.

@Krolik: pomyliłeś topiki? to jest forum o PHP, pytanie jest o PHP i duże projekty, więc sobie o tym JAVA vs PHP pisz w osobnym topiku na hydepark

Pytanie jest o PHP i duże projekty. Wyraziłem tylko opinię, że w dużych projektach PHP nie jest tym co tygryski lubią najbardziej, bo są lepsze rozwiązania i tyle. Może nie na temat?

PHP nigdy nie było projektowane z myślą o dużych systemach. Że niektórzy je stosują na siłę do dużych projektów, bo najpierw projekt był mały, chodził na tanim hostingu, ale zdobył popularność i się rozrósł, to inna sprawa. Ale później są niezłe problemy. Jak mi goście z dużego polskiego portalu opowiadali jakie cuda musieli robić, żeby ostatecznie rozwiązać problem składowania i replikacji sesji, to się zastanawiałem, gdzie sens i logika, skoro w J2EE te rzeczy są gotowe i działają od razu.

Frameworki do budowy aplikacji - wszystko fajnie, jeśli chodzi o funkcjonalność, ale tylko do stron o małym obciążeniu. Narzut czasu wykonania jest ogromny, kiedy taki framework MVC przy każdym requeście musi parsować ponownie wszystkie szablony w XML, tworzyć obiekty, które po zakończeniu skryptu lecą na śmietnik. Są na to jakieś tam obejścia, acceleratory i inne hacki, ale jakbym miał kasę wyłożyc na projekt, to wolałbym, żeby nie był to jeden wielki hack powiązany sznurkami i taśmą klejącą, tylko coś porządnego zaprojektowanego raz a dobrze. Duże serwisy jak Onet, owszem robią w PHP, ale piszą w sposób proceduralny i nie polegają na gotowcach.

BTW: To jakiś niezły WTF macie w tej aplikacji, że musicie restartować wszystko aby zmienić coś w kodzie. W Javie/.NET też można edytować kod bez restartu apikacji. Po kliknięciu "save" zmiany są nanoszone od razu na działający kod. A już ten czas 25 minut to jakiś wielki ROTFL. Robimy duży portal mobilny w J2EE oparty na frameworku komponentowo/zdarzeniowym i odpala się ok. 6-10 sekund na 5 letniej developerskiej maszynie.

spoko, ale nie śmiećcie tutaj o czymkolwiek innym niż PHP. Temat jest jasno sprecyzowany, a miejsce na jakiekolwiek flejmy jest w hydeparku.

//adminie to moj ostatni off o javie w tym temacie - odpowiem krotko przedmówcą

orglee - powiem Ci co to za projekt jak zmienie prace można było podzielić na moduly, ale wcześniej nikt o tym nie pomyślał a teraz brak odważnych

Nie pisałem o maszynie (ja odpalam na 3 letniej), ale serwerze aplikacji (JBoss, GlassFish).

Dobra, pozostając przy PHP: czy są jakieś dobre frameworki do budowania aplikacji komponentowo / zdarzeniowo?
IMHO przy dużych projektach ten sposób programowania jest łatwiejszy, i w przeciwieństwie do proceduralnego, bezstanowego podejścia serwowanego przez większość frameworków MVC (nawet jeśli zaimplementowanych przy użyciu klas i PHP5), w pełni wykorzystuje obiektowość.

PRADO, ale i tak polecałbym zapoznać się z czymś innym.

Dlaczego z czymś innym? Jakie są wady / zalety PRADO?
Czy wydajność w dużym projekcie jest rzeczywiście tak dobra, jak piszą na stronie?
Ktoś się tym bawił?

BTW: znalazłem coś takiego: http://www.avnetlabs.com/php/php-framework...ison-benchmarks
Wynika z tego, że wszystkie te frameworki są okropnie powolne i generują olbrzymie narzuty.

ale jak to ktos madry powiedział: serwer jest tanszy niz programista

Bo miesiąc pracy programisty to serwer, a więc jak coś sprawi że coś zajmie 2 razy mniej czasu, to po miesiącu już się zwróci ten dodatkowy serwer, po dwóch...
Dlatego FW, OOP itd. jest tak rozchwytywane, bo skraca czas tworzenia, poprawiania, modyfikacji, mimo że daje dodatkowy narzut do obciążenia.

To tak jakby narzekać, że lepiej używać kosy bo kombajny są duże, głośne i na drogą benzynę

Hahahaha pięknie podsumowaliście pytanie dlaczego należy używać frameworków ^^
Jednak tutaj pytanie jest zdaje się o wydajność innych i to czy warto pisać własny.

Myślę że na drugie można odpowiedzieć tak...
Jeśli możesz wygospodarować trochę czasu lub widzisz wyraźne irytujące braki w innych młotkach, powinieneś zrobić swój własny.
Pisanie własnego czy też używanie już istniejących niesie ze sobą tyle samo zalet co i wad. O tym czy konstruować własny młotek każdy musi zdecydować sam biorąc pod uwagę wiele drobnych szczegółów. Sytuacja ma się nieco inaczej jeśli dotyczy to firmy i grupy programistów.
W takim wypadku jestem zdania że należy użyć już istniejącego jeśli nie chce się doprowadzić do nierentowności firmy.

No, ja się zgadzam z tym, że czas programisty jest droższy niż sprzętu, ale... różnice w tych benchmarkach są rzędu 10-15x na niekorzyść frameworków w porównaniu z "baseline PHP", a koszty sprzętu to nie jedyne wydatki związane z niższą wydajnością. A kto: będzie to serwisował, płacił za prąd, pilnował by nie wynieśli, udostępniał pomieszczenia? IMHO koszt zbudowania klastra 50 serwerów zamiast 4 może być bardzo duży w porównaniu z kosztem samych skrzynek. Zresztą skrzynki serwerowe tanie nie są. Przecież nie postawię serwisu na sprzęcie domowym w garażu u kolegi. Serwer dedykowany to ok. 5 tys /rok. Stawiając takich 50 łatwo wylecieć z całego budżetu na projekt... Przy projektach, które przewidują duże obciążenie, użycie frameworku PHP przynosi korzyści na początku, ale na dłuższą metę może być ryzykowne.

A jeśli pisać własny, to czy w ogóle da się dorównać wydajności zwykłego proceduralnego PHP?




Ale co, jeśli można mieć kombajn, który nie pali dużo i jest cichy?



Tylko w PHP jest to szczególnie widoczne. W kompilowanych językach narzutu na OOP praktycznie nie ma.

Właśnie takim jeżdżę ale Ty ciągle mimo wszystko mówisz o kosie

Czytam te Wasze analogie i przypomniała mi się rozmowa na GG z nienzjaomym Mi kolesiem na temat frameworków vs. własne rozwiązania.




Nie zrozumiałem tego ostatniego argumentu, ale i tak bladł przy innych Jego wymysłach.

Rozumiem, ze masz na myśli Kohane. A skoro w wątku mowa jest o dużych projektach, to zastanawiam się czy sprawdzałeś jej możliwości w takich projektach. Czy sobie poradziła z naprawdę dużymi serwisami. Na razie z tego co widziałem to projekty na stronie oficjalnej nie są zbyt wygórowane, parę blogów, jakieś stronki z filmikami itp. I z tego co widzę po ogromnych zmianach w Core w wersji 2.3 to raczej długo nic poważniejszego nie zobaczę.

Pozdr