Jaki framework PHPowy polecacie dla duzego portalu

14 MB osiąga MediaWiki razem z dużym zestawem rozszerzeń z SVN Wikimedii. Podkreślam: 14 MB kodu ładowanego przy *każdym* requescie.
ha ha ha . no to sie posmialiśmy, fajnie było
specjalnie na tę okoliczność ściagnieta mediawiki-1.11.0
wczytuje podczas requestu ok 1.4 MB plików. ( w tym tak naprawde tylko ok. 400kB kodu php.)
duzo ale nie 14MB trzeba dodatkowo pamietać oni z zalozenie kozystaja z rozwiazan takich jak Turck MMCache, eAccelerator, APC albo XCache. tak wiec to że tego kodu jest duzo za duzo nie ma wielkiego znaczenie.
No to się teraz pośmiej z tego:
svn.wikimedia.org/svnroot/mediawiki/trunk/extensions
Tzn. Wikipedia z tego korzysta. MediaWiki to najwyżej umożliwia.

Tak do końca nieuzasadnione, to też nie jest. Wyobraź sobie aplikację w PHP, która aby ruszyć, includuje sobie ok. 14 megabajtów kodu. Tak więc przy każdym requescie trzeba te 14 megabajtów kodu na nowo sparsować i większość uruchomić. A aplikacja ciągle rośnie, gdyż z reguły na rozwój
W tym problemie pomaga APC, kod PHP jest parsowany tylko raz (o ile czas modyfikacji pliku nie uległ zmianie), następnie bajtkod przechowywany jest w pamięci, więc odpada dodatkowo narzut na dostęp do dysku. działa dalej. Czyli coś podobnego do autoload, ale niezależnie od tej funkcji i tym samym od wersji PHP.
Jeśli musisz martwić się jeszcze PHP4, nie zazdroszczę. Zastanów się jednak, czy warto.
Ale z tego, co pamiętam, APC wymaga powstrzymania się od używania pewnych technik i ogólnie jest niefajne. Dlatego raczej preferuję prostsze rozwiązanie, tj. squid+memcached.
Nie muszę. Szczerze mówiąc, to już za czasów PHP5 miałem z autoload drobny problem - skoki wydajności w trakcie działania aplikacji, co przy jednym z modułów było nieakceptowalne. Dlatego napisałem sobie coś, co ładuje wszystkie potrzebne klasy na początku i dopiero inicjalizuje moduł. Nie wiem szczerze mówiąc, jak by to działało z autoload na dzisiejszych wersjach PHP5.

No to się teraz pośmiej z tego:
svn.wikimedia.org/svnroot/mediawiki/trunk/extensions
trzeba dodatkowo pamietać oni z zalozenie kozystaja z rozwiazan takich jak Turck MMCache, eAccelerator, APC albo XCache. tak wiec to że tego kodu jest duzo za duzo nie ma wielkiego znaczenie.
Tzn. Wikipedia z tego korzysta. MediaWiki to najwyżej umożliwia.
Any User :
media wiki w WERSJI stabilnej (a nie jakies wynalazki z trunk ) ładuje 1.4 MB plików *.php z czego ok 0.4MB stnowi kod php
zainstalowanie jakiejś niewydanej niestabilnej wersji i wszystkich mozliwych rozszerzeń w wersjach deweloperskich byc może i powoduje że aplikacja działa wolno i że ładuje dużo plików.
zwłaszcza jeżeli nie przeprowadzisz instalacji do końca i nie zainstalujesz jakiegoś akceleratora z rodzaju mmcache

Mediawiki zostało napisane z myslą o zastosowaniu w wikipedii. I majac swiadomość tego że bedzie to serwis o sporej ilosci uzytkowników zdecydowano sie na pewne konkretne rozwiazania dotyczące optymalizacji.
Pisanie aplikacji z zamysłem uzycia akceleratorów prekompilujacych kod źródłowy sprawia ze nieco inaczej podchodzi sie do organizacji kodu zródłowego (nie zebym nie odczówał obrzydzenia jak to oglądam)
wiec NIE, nie jest prawda, jak piszesz, że w przypadku MediaWiki przy wywołaniu strony aplikacjia musi załadować 14MB kodu php.
Napewno nie w przypadku kiedy jest poprawnie skonfiurowana
troche tak jak byś narzekał że nowe Ferrari bardzo kiepsko jeździ po tym jak pan Waldek z warsztatu na rogu wymienił silnika i skrzynie biegów na model z duzego fiata i nie łaczył tych dwóch rzeczy w ciąg logiczny
z

zdzisio no wiec tysiac godzin to może i jest optymistyczny szacunek, a moze wcale nie. zalezy głównie od tego co to miało by byc.
Pytam, bo liczba wygląda na wziętą z sufitu - i z Twojej odpowiedzi wnioskuję, że chyba faktycznie taką jest.
Adam Byrtek :
liczyłeś na to że siądę i napisze wstepna dokumentacje projektową dla frejmłorka do projektu o którym wiem dokładnie tyle że "ma byc duzym portalem" i na podstawie tego udziele ci precyzyjnej odpowiedzi na pytanie o kosztorys?
z.