Chciałbym wypróbować kilka różnych zabiegów optymalizacyjnych w swojej aplikacji. Jak to z optymalizacją bywa często można popsuć zamiast poprawić, więc przydadzą się jakieś testy. O ile ze skryptami po stronie serwera nie ma problemu, to po stronie klienta jest dużo ciężej. Mogę niby sprawdzać to używając firebuga/Yslow itp. itd. ale ciężko jest symulować różne środowiska w jakich działają użytkownicy. Szczególnie, że ze 20% dalej ma naszą kochana 8 letnia przeglądarka.
Najprostsze rozwiązanie jakie przychodzi na myśl:
Na samym początku w head javascript zapisuje datę w milisekundach.
Na końcu liczy się różnicę czasu i zapisuje do logów (pewnie jakiś GET pobierający pusty gif z parametrami).
Po umieszczeniu tego w produkcji można by wyciągnąć całkiem reprezentatywną średnią (warto pewnie zapisać przeglądarki).
Zanim to jednak wrzucę, żeby sprawdzić chciałem zapytać czy ktoś przypadkiem nie testował takiego lub innego rozwiązania.
http://wrug.eu/ – Test By Proxy. Na razie jest tylko pierwsza prezentacja, ale ona właściwie prezentuje clou całego rozwiązania wraz z co ważniejszym kodem (kod na slajdach akurat dotyczy logowania czasu załadowania strony plus wszystkich obrazków – co chyba wyczerpuje temat). Czeka Cię trochę zabawy z JRuby, Greasespoon i postawieniem ciekawego serwera proxy na maszynie / po drodze do maszyny klienckiej
I cholera teraz się pytam - dlaczego o tym nie pamiętałem?
Update:
A po przejrzeniu slajdów, przypomnieniu i krótkim przemyśleniu: to nie mój przypadek
Sposób Mike’a jest genialny gdy nie mam kontroli nad zawartością - w jego przypadku to były reklamy z tego co pamiętam.
W moim przypadku mogę sobie taki skrypcik zliczający obrazki wrzucić sam, robienie proxy było by tutaj przerostem formy nad treścią Chyba, że czegoś nie rozumiem.
Pytanie tylko jak to ma dokładnie wyglądać ? Czy liczyć czas od momentu załadowania strony, czy zapisywać już w railsach i później sprawdzać różnicę między czasem zapisanym w railsach i tym zapisanym przez ostatni obrazek?
@Drogomir: Czekaj, to w końcu chcesz testować:
a) czas załadowania htmla
b) czas załadowania htmla, cssa, obrazków i całej reszty contentu
c) czas załadowania i wykonania javascriptów “onload”
d) b+c
?
Czyli czas załadowania strony z całym szmelcem. Ile mija od momentu, kiedy użytkownik połączy się z serwerem do czasu kiedy może już spokojnie korzystać ze strony i wszystkich javascriptowych bajerów.
Ale to właściwie nie robi różnicy, po prostu proxy się przyda tylko jak nie mam dostępu do contentu. Mike tam dorzuca funkcję onload do jakiejś strony, która nie jest jego własnością - ja przecież mogę to u siebie wrzucić sam
No to sorry, ale ja niespecjalnie widzę możliwość łupnięcia tego wszystkiego za jednym zamachem.
Czas załadowania strony z obrazkami i cssami – proste jak diabli, np. tak jak Mike zrobił w test_by_proxy.
Czas wykonania wszystkich js-ów onload – też proste, pierwszy onload inicjalizuje timer, ostatni liczy deltę.
Ale jedno i drugie na raz… no po prostu nie widzę tego. Pozostaje paskudne sumowanie
Kiedyś przerabiałem pewien opensourcowy serwer po to, żeby automatycznie generować obrazki stron.
Najskuteczniejsza okazała się metoda, w której serwer gdy tylko otrzymywał zapytanie zapisywał czas startowy, a gdy FF skończył renderować porównywał te czasy. To trochę inny przypadek, bo wszystko robił serwer - to znaczy wczytywał czas generowania gdy dostał sygnał zakończenia od gecko. Podobnie kiedyś zrobiłem właśnie z mongrelem dla developmentu, czy lighttpd jeszcze w PHP, czyli tak jak Drogus mówisz:
quote=drogus
zapisywać już w railsach i później sprawdzać różnicę między czasem zapisanym w railsach i tym zapisanym przez ostatni obrazek?[/quote]
i byłem zadowolony z tego jak działa.
Później używałem już tylko narzędzi typu:
tuneup czy web page speed report,
bo doszedłem do tego, że czasy użytkowników mogą różnić się tak znacznie z różnych względów, że średnie wyniki nigdy nie będą reprezentatywne (np. ktoś ma odpalonego torrenta na maksa czy czort wie co tam jeszcze - a inny ma obrazki w cache lub w ogóle ich nie pobiera). Wg. mnie, to przypadek gdy nie ma sensu się w to bawić, poza środowiskiem czysto laboratoryjnym.
Ja mam na ten temat inne zdanie. Jeżeli 40-60% użytkowników otwiera stronę z pustym cache’em (to akurat zbadali w YUI: http://yuiblog.com/blog/2007/01/04/performance-research-part-2/), a połowa ma zajechane łącze, to właśnie te czasy chcę porównywać. Oczywiście przydadzą się też testy laboratoryjne, ale co mi to da, że u siebie na firefoxie będę uzyskiwał mega szybkie wczytywanie, a połowa użytkowników (IE?) będzie jęczała, bo im się ślimaczy. Nie należy też przesadzać, ale chciałbym to jednak wziąć pod uwagę.
Subiektywnego odczucia czasu ładowania strony nie zmierzysz / nie potwierdzisz / nie zaprzeczysz “laboratoryjnymi” benchmarkami. Subiektywne odczucie czasu ładowania strony zmierzysz sadzając kilka różnych osób przy swoim serwisie z użyciem różnych przeglądarek. I to chyba tyle w temacie
