Witam, chcę zapytać czy ktoś zgodzi się z tezą że MVC spowalnia działanie stron. Chodzi mi o to że jeśli najpierw model pobiera wszystkie potrzebne dane a potem dopiero są wszystkie wyświetla, trzeba bez sensu czekać na załadowanie danych, gdy podczas zwykłych, standardowych stron, mogli byśmy korzystać z metody flush(). Co o tym sądzicie? A może znacie jakieś inne, sprytne rozwiązania.

W ogóle, obiektowy model (paradygmat) spowalnia działanie skryptów. Bez paranoi; jeśli byś pisał wszystko strukturalnie, to przy większych projektach więcej czasu straciłbyś na poszukiwaniach gdzie-co-jest niż stratach w generowaniu stron.


To znaczy? Jakoś nie bardzo sobie to jestem w stanie uzmysłowić.

Wiem że struktura nie jest fajna, ale chodzi mi o to że jeśli mamy dajmy na to nasza klasę, to można zauważyć, że elementy ładują się kolejno, ale nie jest to realizowane za pomocą żadnych skryptów. I jeśli mam powiedzmy bazę danych, na której siedzi w tym samym momencie około 100000 userów baza będzie działała wolno. Co jeśli działali byśmy na zasadzie: weź dane, wypisz (flush), następne zapytanie select, kolejny flush i powinno działać to szybciej. Tym czasem MVC pobiera wszystko (wszystkie zapytania do bazy) następnie dopiero rysuje widoki.

Moim zdaniem nawet jeśli przyniosłoby to jakieś korzyści w postaci wzrostu wydajności, to koszt sprzętu niwelującego tą różnicę przy modelu obiektowym byłby znacznie mniejszy nakładu dodatkowego czasu potrzebnego na modyfikację takiego serwisu.

No jak nie...? Przecież wiele elementów, to skrypty JS działające na zasadzie progressive enhancement...


To raczej nie kwestia obciążenia CPU, ale pamięci.

moze lekko nie na temat ale polecam ten filmik albo ksiazke ktora ten osobnik (autor wtyczki YSlow do firebuga) napisal: http://www.youtube.com/watch?v=BTHvs3V8DBA

Moje doswiadczenia sa podobne, o malo nie dalem sie zwariowac na punkcie optymalizacji mvc, srubujac czasu pomiedzy operacjami o kolejne microsekundy ale powyzszy filmik rzucil nowe swiatlo na optymalizacje.
Wg Steve'a 5% rezultatu optymalizacji przypada na strone serwera a pozostale 95% na strone klienta
Nie umniejszajac waznosci pisania szybkiego kodu php i jego optymalizacji mozna zauwazyc ze optymalizujac php operuje sie na microsekundach a optymalizujac juz wygenerowany html operuje sie na sekundach co przeklada sie na fizyczne skrocenie czasu zaladowania strony

obiektowka spowalnia, oczywiste i pozera wiecej pamieci ale straty wg mnie z tym zwiazane sa znikome w porownaniu do plusow
aby minimalizowac te straty mamy mnostow mechanizmow do dyspozycji, chociazby cacheowanie na roznym poziomie, od query cache poczawszy przez cachowanie wynikow zapytan na poziomie php czy cachowanie widowko czy tez calego buffor'a. Czas generowania stron z kilkupoziomowym cachem niewiele odbiega od czasu generowania strukturalnego php czy statycznego html

Luzny przyklad jednego z projektow
1. zoptymalizowany mvc z 3 zapytaniami wykonuje sie w 0.013s
2. zoptymalizowany mvc 3 widoki z cache wykonuje sie w 0.0011s
3. zoptymalizowany mvc caly z cache wykonuje sie w 0.0009s
4. statyczny html 0.0004s
Laczny czas ladowania html do przegladarki 2.2s z czego jak widac wygenerowanie koncowego htmla z php jest znikoma czescia procesu

1. optymalizacja z uzyciem YSlow etags, expires headers skraca czas z 2.2s do 0.9s przy drugim ladowaniu
2. "css spread" lub rozlozenie obrazkow na 2 subdomeny skraca czas do 0.55s
3. przelozenie css na gore HEAD i JS tuz przezd </BODY> skraca czas jedynie do 0.45 aczkolwiek uzytkownik widzi strone duzo szybciej

Ktos ma jakies doswiadczenia w tym kierunku? gdzie co i jak drastycznie przyspiesza strone?

Zawsze pozostaje ci przejsc na klasyczny wzorzec SC, lub TBWK.


*) SC = spagetti code [sql + php + html wymieszany obok siebie]
TBWK = totalny balagan w kodzie

@guitarnet.pl: Odnośnie optymalizacji, tej części po stronie klienta dorzucę parę jeszcze:
4. Kompresja js
5. Złączenie wielu plików js i css w jeden (oczywiście jeden js i jeden css )
6. css sprite - czyli łączenie pojedynczych obrazków w jeden (przykład jquery ui)

@vokiel: swieta prawda

4. kompresji js osobiscie unikam ze wzgledu na dziwne zachowanie jquery, zaobserwowalem bledy js zglaszane przez firebuga z silnika jquery podczas gdy niekompresowany plik js nie mial tych bledow, co najdziwniejsze losowo, polecam natomiast minimalizacje bialych znakow co jest nieszkodliwe zarowno css jak i js
alternatywnie do kompresji js mozna wlaczyc gzip, przy zalozeniu ze te 20% ludzi ktorzy uzywaja przegladarek bez gzipa nie zobaczy strony, kwestia podejscia

z wlasnych eksperymentow moge powiedziec ze przerzucenie wszystkich plikow JS na koniec pliku html zamiast w HEAD daje przyspieszenie ponad 50%. W wiekszosci przegladarek jak napotkane zostanie <script> to przegladarka czeka na calkowite sciagniecie tego pliku i wstrzymuje renderowanie strony i sciaganie innych plikow
mozna ten proces dokladnie zobaczyc w zakladce NET firebuga

Przeglądarki serwują Ci takie coś jak HTTP_ACCEPT_ENCODING na podstawie którego możesz określić czy dana przeglądarka obsługuje gzip czy nie.

Bujda na kółkach. Opłaci się gzipnąć i wysłać do klienta. Dekompresja kodu JS nieraz zajmuje parę sekund, pogooglaj, a znajdziesz odpowiednie materiały.


Nieraz tak się nie da... Choćby powtarzalne tła. Elementy interfejsu - owszem, ale tła - w większości przypadków nie da rady.

Odnośnie kompresji js źle się wyraziłem, miałem na myśli usunięcie zbędnych znaków, w taki sam sposób można postąpić z css. Nie chodziło mi o kompresję na zasadzie zastępowania nazw funkcji etc. Użyłem złego słowa.
A co do usuwania zbędnych znaków powoduje to tylko zmniejszenie objętości plików, co za tym idzie ciut szybsze ściąganie u klienta.

@erix
Tak jak najbardziej, nie da się wszędzie użyć css sprite. Ale jest to bardzo przydatne w przypadku wielu małych ikonek, typu te w edytorach WYSIWYG. Co jedno żądanie i pobranie jednego pliku to nie 30

@vokiel
wersja z usunieciem bialych znakow to nazywa sie minified
wersja pliku compressed to w przypadkach w ktorych sie spotkalem uzywa np base62 encode wliczajac w to zmiane powtarzajacych sie nazw zmiennych, funkcji itp
kompresja gzip to co innego aczkolwiek zgodze sie ze nalezy uwaznie stosowac obie wersje

@erix
zgodze sie, z moich doswiadczen wynika ze np jquery kompresowany base62 ma tendencje do dziwnych zachowan (o czym wspomina Steve w powyzszym filmie) jak zauwazyles taka dekompresja pochlonie jakis czas, czy to wewnetrzna base62 czy gzip, warto sprawdzic czy zaoszczedzony czas na transferze np 150kB jest wiekszy niz sciagneiciu 15kB i dekompresji szczegolnie na wolniejszych przegladarkach/komputerach, w moim przypadku ma
zastanawiam sie jednak jak ma sie algorytm gzip do kompresji base62, co lepsze, wady, zalety, tu troche brakuje mi wiedzy?


jest jeszcze jeden aspekt - ladowanie reklam.. ostatnio zauwazylem bardzo duze problemy arbomedii, smartcontext i tradedoubler przy ladowaniu ich plikow, jakkolwiek zoptymalizuje strone to wszystko pada na leb jak tylko napotka na jeden z tych plikow,
mistrzem jest smartcontext ktory laduje podwojnie wiekszosc plikow, laduje w ciemno biblioteke jquery 55kB i 90% z plikow uzywa naglowka 301 dla swoich gif'ow i js.. porazka. czas ladowania zoptymalizowanej strony spada z 1.12s do 6s

Ja sobie kompresor base62 darowałem, gzipa zostawiam.

O ile base62 jest męczony przez silnik JS, to gzip przez natywne mechanizmy przeglądarki (patrz: kompresja strumienia HTTP). Wnioski nasuwają się same.