php a duże projekty., Jakie środowisko używać. Opcje

[Krolik]

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

[Cysiaczek]

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.

[Krolik]

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

[mrok]

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

[starach]

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 ?

[sf]

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.

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

[Krolik]

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.

Ten post edytował Krolik 13.09.2008, 11:52:44

[nrm]

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

[mrok]

//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

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.

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

[Krolik]

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

[LBO]

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

[Krolik]

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.

Ten post edytował Krolik 16.09.2008, 10:31:49

[kwiateusz]

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

[Sedziwoj]

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.

[nrm]

Wynika z tego, że wszystkie te frameworki są okropnie powolne i generują olbrzymie narzuty.

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

[starach]

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.

[Krolik]

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?

Wynika z tego, że wszystkie te frameworki są okropnie powolne i generują olbrzymie narzuty. sad.gif

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

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

Dlatego FW, OOP itd. jest tak rozchwytywane, bo skraca czas tworzenia, poprawiania, modyfikacji, mimo że daje dodatkowy narzut do obciążenia.

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

[nrm]

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

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

[LBO]

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.

:nieznajomy:
nie, po prostu uwazam ze nie zatrudniam calej druzy pilkarskiej do strzelenia gola do pustej bramki
alan 11:14:50
Tak, ale mozesz miec takiego trenera, ktory wystawi tylko jednego gracza
:nieznajomy:
tylko ** ***** mam placic za pozostalych 10 zawodnikow i samego trenera

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

:nieznajomy:
projektuje sie na potrzeby a nie na wyrost
:nieznajomy:
wrzucasz folder 10GB na dysk a potem go otwierasz i usuwasz 9.99GB bo potrzebujesz z niego tylko 1 plik tekstowy!?
alan 11:30:06
ale co to za argument? skoro masz framewrok o swietnej architekturze pozwalajacej na niemal wszystko
alan 11:30:12
i mozesz wylaczyc
alan 11:30:15
to czego nie potrzebujesz
alan 11:30:20
nie chcesz bazy
alan 11:30:26
wylaczasz obsluge bazy
alan 11:30:29
nie chcesz loggerów
alan 11:30:33
wylaczasz loggery
alan 11:30:44
nie chcesz autoryzacji, ba - nie ma sprawy
alan 11:30:48
i nie korzystasz z nich
alan 11:31:12
....po czym nagle klient prosi zby mu dorobic zarzadzanie userami z logowaniem etc
alan 11:31:15
to co robisz?
:nieznajomy:
to po co ma byc na serwerze 90% niepotrzebnych rzeczy?
alan 11:31:22
wlaczasz autoryzacje
alan 11:31:27
dodajesz maly modul
alan 11:31:29
i po prawie
alan 11:31:37
jak to 90%?
:nieznajomy:
chyba tylko jako potencjalne dziury do wykorzystania
alan 11:31:39
chodzi tobie
alan 11:31:45
o źódła frameworka?
alan 11:31:51
źródła?

:nieznajomy:
jak mowilem - to nie nasa
:nieznajomy:
kiedys poszedlem do firmy, pogadalem chwile i pytam na jakim systemie pracujecie, a oni ze na ezPublish i joomli, z miejsca podziekowalem i wyszedlem
alan 11:43:33
skoro tak twidzisz, nie chce ciebie przekonywac, bo wydajesz sie nieroformowalny - z argumentami typu, źródeł zajmujacych miejsce na serwerze.
:nieznajomy:
dla mnie firma ktora korzysta z rozwiazan opensource to firma ktora nie potrafi zrobic nic swojego

[kbsucha]

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

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