Profilowanie aplikacji |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
Profilowanie aplikacji |
27.03.2007, 16:03:15
Post
#1
|
|
Grupa: Moderatorzy Postów: 36 519 Pomógł: 6308 Dołączył: 27.12.2004 |
Zgodnie z życzeniem: "Profilowanie aplikacji".
Zachęcam do udziału w dyskusji -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
27.03.2007, 20:04:01
Post
#2
|
|
Grupa: Przyjaciele php.pl Postów: 384 Pomógł: 6 Dołączył: 11.09.2004 Skąd: Grodzisk Mazowiecki Ostrzeżenie: (0%) |
Myślę że śmiało można by zmienić nazwę tematu na "Profilowanie i debugowanie aplikacji" bo z reguły wrzuca się to do jednego worka.
A teraz do rzeczy. Chętnie posłuchał bym osób dla których jest to chlebem powszednim. Sam mam stosunkowo małą wiedzę na ten temat. Na pewno warto wspomnieć o xdebug. Bardzooo popularne narzędzie o którym każdy programista PHP na pewno słyszał. Jest to rozszerzenie PHP które przydante jest przy debugowaniu. Dodatkowo na storonie projektu znajduje się Profiler (WinCacheGrind - Windows oraz KCacheGrind - Linux) gdzie ładnie pokazywane są słupki z czasami. Od razu widzimy co muli a co nie http://xdebug.org/ Spotkałem się również z jMeter. Zaawansowane narzędzie do mierzenia wydajności, napisane w Javie rozwijane przez Apache Software Fundation. Pierwszy raz przeczytałem o nim w PHP Solutions. W numerze 1/2005 (7) znajduje się bardzo obszerny artykuł opisujący użycie tego zaawanego narzędzia, bo takim jest jMeter. Przy jego pomocy można tworzyć sztuczny ruch urzytkowników, którzy robią różne rzeczy. Przykładowo jeden przegląda newsy, drugi w innym miejscu aplikacji wysyła jakiś formularz. Możemy w ten sposób sprawdzić naszą aplikację w skrajnie ekstremalnych warunkach i zobaczyć jak się ona zachowuje. http://jakarta.apache.org/jmeter/ To tyle ode mnie. Co wy macie do powiedzenia na ten temat ? -------------------- |
|
|
5.04.2007, 17:44:13
Post
#3
|
|
Grupa: Zarejestrowani Postów: 77 Pomógł: 5 Dołączył: 29.03.2006 Skąd: Poznań Ostrzeżenie: (0%) |
W PHP Solution ostatnio ukazał się artykuł na temat benchmarku, można go ściągnąć za darmo Testy wydajności i profilowania aplikacji PHP
-------------------- Blog | Strona www | wicia.pl
|
|
|
23.04.2007, 16:04:42
Post
#4
|
|
Grupa: Zarejestrowani Postów: 27 Pomógł: 0 Dołączył: 22.11.2003 Ostrzeżenie: (0%) |
Luzne mysli profilerskie
1. Nie optymalizuj dopoki wydajnosc nie jest problemem 2. Pamietaj o zasadzie 20/80 - 20% kodu zajmuje 80% czasu wykonania. Nie optymalizuj reszty. 3. Profiler z Zend Studio miewa humory, czasami trzeba kilka razy odswiezyc, zeby wylapac prawdziwe wyniki -------------------- Robert Janeczek
G-Forces Web Management Polska robert.janeczek@gforces.pl |
|
|
24.04.2007, 06:55:44
Post
#5
|
|
Grupa: Zarejestrowani Postów: 54 Pomógł: 0 Dołączył: 25.09.2006 Ostrzeżenie: (0%) |
Nie optymalizuj dopoki wydajnosc nie jest problemem Kwestia dość sporna. Bo niby skąd osoba początkująca ma wiedzieć czy wydajność jest problemem w jego aplikacji czy nie. Dlatego wg. mnie bardzo dobrym nawykiem jest nauka profilowania zaraz po zapoznaniu się z podstawami PHP. Cytat Im mniej tworzysz testów, tym stajesz się mniej produktywny, a twój kod staje się mniej stabilny
-------------------- skocz.org - system skracania linków
|
|
|
24.04.2007, 08:28:37
Post
#6
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
Wydaje mi się, że trudno nauczyć się profilowania zaraz po zapoznaniu się z podstawami php - profilowanie jest dosyć trudne i trzeba na prawdę wiedzieć co się robi. Zgodzę się tu z rashidem, że po prostu są rzeczy, których nie ma sensu poprawiać - ale aby dowiedzieć się, które to są trzeba trochę doświadczenia.
Interesuje mnie natomiast czego używacie do profilowania i jak to się u was sprawdza. Ja dopiero zaczynam zabawę z profilowaniem i na obecnym stanie wiedzy to jeszcze długo będzie zabawa. Z większych aplikacji testowałem na razie APD - trochę toporne narzędzie, ale wyniki daje dość przekrojowe. Powiem szczerze, że bez dobrego tutoriala na temat profilowania to jest raczej jak błądzenie we mgle - coś to daje, ale interpretacja wyników jest dosyć trudna. Temat zamierzam trochę rozpoznać w okolicach wakacji, gdy będzie więcej czasu. |
|
|
24.04.2007, 12:45:51
Post
#7
|
|
Grupa: Zarejestrowani Postów: 27 Pomógł: 0 Dołączył: 22.11.2003 Ostrzeżenie: (0%) |
Kwestia dość sporna. Bo niby skąd osoba początkująca ma wiedzieć czy wydajność jest problemem w jego aplikacji czy nie. Jak to skad? Z informacji od klienta/uzytkownikow. Programista bardzo rzadko jest w stanie okreslic co nalezy zoptymalizowac i czy w ogole trzeba. Sa systemy, w ktorych czas odpowiedzi w przypadku niektorych operacji wynosi kilkadziesiat sekund i nikt na to nie narzeka. Dlatego wg. mnie bardzo dobrym nawykiem jest nauka profilowania zaraz po zapoznaniu się z podstawami PHP. Poklikanie sobie w profilerze i pobawienie sie w profilowanie swojej malej aplikacji - jak najbardziej. Co innego zabieranie sie za optymalizacje dla samej optymalizacji -------------------- Robert Janeczek
G-Forces Web Management Polska robert.janeczek@gforces.pl |
|
|
1.05.2007, 12:08:40
Post
#8
|
|
Grupa: Zarejestrowani Postów: 176 Pomógł: 0 Dołączył: 30.11.2004 Ostrzeżenie: (0%) |
zanim zaczniecie używać jakichkolwiek benchmarków/profilerów itp. poczytajcie sobie co lepiej użyć w kodzie, aby był on optymalnie napisany (oczywiście php4 a php5 to różnica). Już samo użycie sizeof czy count odgrywa różnicę, nawet jeśli są to setne sekundy to przy dużym obciążeniu serwera itd. może to odegrać duże znaczenie. Myśląc tak przy samym poziomie pisania kodu możemy pisać naprawdę optymalne rozwiązania, oczywiście potem już pozostaje przyjrzenie się użytemu algorytmowi i w tym pomocne mogą się okazać w/w narzędzia.
-------------------- |
|
|
1.05.2007, 12:58:46
Post
#9
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
Wydaje mi się, że jest to podejście od złej strony.
Oczywiście różnice są - ale IMHO są one na tyle małe, że nie należy nimi sobie zbytnio zawracać głowy. Oczywiście można gdybać, że gdyby to był duży popularny serwis itd itp... ale gdy to będzie duży popularny serwis to sobie dokupią sprzętu :-) Oczywiście nie zrozum źle mojej wypowiedzi - warto wiedzieć takie rzeczy i starać się je stosować, ale na podobnej zasadzie można by zrezygnować z OOP bo jest przecież wolniejsze. Tyle tylko, że znowu są to tysięczne sekundy różnicy. Zresztą w kolejnej wersji PHP mogą zupełnie zmienić implementacje danej funkcji. Natomiast różnice wynikające z optymalizacji algorytmu mogą być naprawdę znaczące. Profilowanie pomage znaleźć wąskie gardła, na których aplikacja zwalnia. Skłaniam się tu nawet do wypowiedzi rashid'a, że w dzisiejszych czasach nie warto optymalizować na siłę całej aplikacji, a skupić się tylko na tych ważniejszych elementach, gdzie spadki wydajności są zauważalne i mogą być bolesne. |
|
|
1.05.2007, 14:10:55
Post
#10
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) |
zanim zaczniecie używać jakichkolwiek benchmarków/profilerów itp. poczytajcie sobie co lepiej użyć w kodzie, aby był on optymalnie napisany (oczywiście php4 a php5 to różnica). Już samo użycie sizeof czy count Masz może gdzieś pod ręką taki spis/test najpopularniejszych funkcji/etc ? -------------------- ”Godzina nauki w życiu nowoczesnego apostoła jest godziną modlitwy.”
(św. Josemaría Escrivá, Droga, 335) |
|
|
1.05.2007, 17:17:01
Post
#11
|
|
Grupa: Zarejestrowani Postów: 219 Pomógł: 5 Dołączył: 18.07.2006 Skąd: Piekary Śląskie Ostrzeżenie: (0%) |
Już samo użycie sizeof czy count odgrywa różnicę, nawet jeśli są to setne sekundy to przy dużym obciążeniu serwera itd. Trochę mnie zaintrygowałeś tym, że jest jakaś różnica pomiędzy sizeof i count bo w manualu pisze, że sizeof jest aliasem dla count. Zrobiłem więc pomiar. Wziąłem duuużą tablicę, i zmierzyłem jej wielkość 100000 razy - najpierw sizofem potem countem. Różnice czasowe były na korzyść counta jednak mieściły się w granicach niepewności pomiarowej. Co więcej, jeśli zamieniłem je kolejnością badania... czyli najpierw zmierzyłem 100000 razy funkcję count a potem sizeof to sytuacja się odwróciła i to sizeof było szybsze... co prawda też minimalnie. Wniosek jest jeden - różnic nie ma. Teraz chciałbym napisać coś w temacie. Wszyscy patrzycie na kwestię profilowania i wydajności aplikacji przez pryzmat wygody klienta czyli tego jak szybko mu program będzie działał. Ja patrzę na to troszkę inaczej. Mianowicie przymierzam się do kupna serwera i jego kolokacji w centrum danych. Na tym kompie będą umieszczane strony moich klientów. Od tego jak optymalnie napiszę swój kod zależeć będzie ile stron będzie mogło chodzić na jednej maszynie. Więc im lepiej napiszę swoje strony tym mniej serwerów będę musiał utrzymywać i tym moje koszty będą mniejsze. Pozdrawiam. -------------------- CMS dla Twojej firmy
Wojciech Małota |
|
|
1.05.2007, 18:47:29
Post
#12
|
|
Grupa: Zarejestrowani Postów: 176 Pomógł: 0 Dołączył: 30.11.2004 Ostrzeżenie: (0%) |
różnice są wszystko zależy od tego w jakiej wersji php to robiłeś i jakie było środowisko badane, musiałbyś zrobić to badanie tym samym narzędziem i w tym samym środowisku, o ile wiem w php4 różnicy nie ma, ale to są właśnie te niuanse..niestety site na którym to znalazłem nie zawiera już tych danych.. a można było porównać php4 z php5.
ale coś znalazłem takiego..ale tamten artykuł był o wiele bogatszy.. Porównanie Ten post edytował marast78 1.05.2007, 18:55:25 -------------------- |
|
|
1.05.2007, 19:03:40
Post
#13
|
|
Grupa: Zarejestrowani Postów: 853 Pomógł: 25 Dołączył: 27.08.2003 Skąd: Katowice Ostrzeżenie: (0%) |
@marast78, to porównanie między php4 i php5 ma się nijak do tematu niniejszego wątku.
osobiście podzielam zdanie athabusa, nie należy oczywiście lekceważyć optymalizacji, ale większą uwagę należy zwrócić na profilowanie, bo właśnie tutaj wychodzą wąskie gardła, które często pożerają więcej niż te dzisiętne części milisekund. -------------------- "If debugging is the process of removing bugs, then programming must be the process of putting them in..."
sobstel.org |
|
|
1.05.2007, 19:09:13
Post
#14
|
|
Grupa: Zarejestrowani Postów: 219 Pomógł: 5 Dołączył: 18.07.2006 Skąd: Piekary Śląskie Ostrzeżenie: (0%) |
różnice są wszystko zależy od tego w jakiej wersji php to robiłeś i jakie było środowisko badane, musiałbyś zrobić to badanie tym samym narzędziem i w tym samym środowisku, o ile wiem w php4 różnicy nie ma, ale to są właśnie te niuanse..niestety site na którym to znalazłem nie zawiera już tych danych.. a można było porównać php4 z php5. Ja swoje badanie robiłem na swoim lokalnym kompie z Win XP Pro, Apache 2.2, PHP 5.2.0. Obydwie funkcje były testowane zaraz po sobie. Podczas testu był wyłączony antywirus i wszystko inne co mogłoby mieć wpływ na wyniki. Kod testu wyglądał mniej więcej tak:
Wynik testu: count: 7.9690039157867 sizeof: 7.9895031452179 Potem zmieniłem kolejności wywołań:
Wynik był taki: sizeof: 7.9034969806671 count: 8.0151460170746 Jak widać różnic w zasadzie nie ma. -------------------- CMS dla Twojej firmy
Wojciech Małota |
|
|
1.05.2007, 20:04:49
Post
#15
|
|
Grupa: Zarejestrowani Postów: 176 Pomógł: 0 Dołączył: 30.11.2004 Ostrzeżenie: (0%) |
nie chce prowadzić konwersacji na ten temat, chciałem tylko pokazać, że na to też warto zwrócić uwagę i w jakimś stopniu optymalizacja wiąże się z profilowaniem, skończmy ten wątek ;]
-------------------- |
|
|
1.05.2007, 20:19:31
Post
#16
|
|
Grupa: Zarejestrowani Postów: 27 Pomógł: 0 Dołączył: 22.11.2003 Ostrzeżenie: (0%) |
Teraz chciałbym napisać coś w temacie. Wszyscy patrzycie na kwestię profilowania i wydajności aplikacji przez pryzmat wygody klienta czyli tego jak szybko mu program będzie działał. Ja patrzę na to troszkę inaczej. Mianowicie przymierzam się do kupna serwera i jego kolokacji w centrum danych. Na tym kompie będą umieszczane strony moich klientów. Od tego jak optymalnie napiszę swój kod zależeć będzie ile stron będzie mogło chodzić na jednej maszynie. Więc im lepiej napiszę swoje strony tym mniej serwerów będę musiał utrzymywać i tym moje koszty będą mniejsze. Każdy patrzy na profilowanie również pod kątem minimalizacji wykorzystania zasobów. Optymalizacja podczas pisania aplikacji (zanim projekt ruszy) nic ci nie da, bo nie wiesz co trwa długo, a przez to obciąża ci system. W ten sposób spędzisz kilka dni na dopieszczanie funkcji która jest wywoływana raz na tydzień. Jaki z tego zysk? Żaden. Twoim podstawowym narzędziem będą logi i profiler. Z logów dowiesz się, co jest wykorzystywane najczęściej, a profiler powie co w tym jest najwolniejsze. Po dłuższych zabawach w optymalizacje aplikacji webowych mogę bez wahania powiedzieć, że w 99% przypadków faktyczna przyczyna spowolnień nawet mi przed profilowaniem przez myśl nie przeszła. Błądzenie po omacku nic nie pomoże, a można stracić masę czasu. PS. Przed podjęciem decyzji o kupnie i kolokacji pogooglaj za Amazon EC2. Może się przyda, może nie... -------------------- Robert Janeczek
G-Forces Web Management Polska robert.janeczek@gforces.pl |
|
|
25.05.2007, 15:01:48
Post
#17
|
|
Grupa: Zarejestrowani Postów: 382 Pomógł: 0 Dołączył: 29.11.2005 Skąd: :jestem(); Ostrzeżenie: (0%) |
Korzystam z xDebug ale dla zainteresowanych link
-------------------- Powyższy post wyraża jedynie opinię autora w dniu dzisiejszym. Nie może on służyć przeciwko niemu w dniu jutrzejszym. Ponadto autor zastrzega sobie prawo zmiany poglądów, bez podawania przyczyny.
|
|
|
28.06.2007, 15:54:58
Post
#18
|
|
Grupa: Zarejestrowani Postów: 426 Pomógł: 32 Dołączył: 24.05.2007 Ostrzeżenie: (0%) |
Ja też uważam że powinniśmy zwracać uwagę na to jakich funkcji wewnętrznych używamy np.: rand() czy mt_rand(), itd...
-------------------- |
|
|
3.07.2007, 14:43:02
Post
#19
|
|
Grupa: Zarejestrowani Postów: 569 Pomógł: 0 Dołączył: 17.08.2003 Skąd: Dąbrowa Górnicza Ostrzeżenie: (0%) |
ja osobiscie nie zawsze mialem dostep do servera zeby dodac xdebug lub inne rzeczy wiec poslugiwalem sie nie zawsze idealnym narzedziem ale za to jakos dzialajacym, Napisalem wlasny skrypt, ktory mial za zadanie zbieraz informacje z kolejnych flag. W kodzie zostawialem przy krytycznych miejscach flage z opisem na poczatku i na koncu jakiejs metody a na koncy wyswietlalem wyniki pokazujac ronice miedzy kolejno wywolywanymi flagami. Jest to dosc nieprecyzyjna, lecz skuteczne metoda jesli nie mamy mozliwosci instalacji xdebuga lub innego rozszerzenia.
A dla ciekawostki powiem jeszcze taki cytat: 20% kodu wykonuje sie przez 80% czasu skryptu. Tlumaczenie dosc wolne ale sens mam nadzieje zachowany -------------------- Warsztat: Linux: PHP, MySQL, Apache, NetBeans, C++, Qt-Creator
Użytkownik, słowo którego specjaliści IT używają, gdy chcą powiedzieć idiota Zarządzaj swoim budżetem domowym |
|
|
5.07.2007, 11:27:57
Post
#20
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
Sh4dow poruszył dosyć ciekawą kwestię, przez którą wczoraj straciłem cały dzień...
Nie zawsze jest pełny dostęp do serwera docelowego i xdebuga można sobie zainstalować tylko lokalnie. Wiadomo jednak, że lokalnie to można przetestować sobie coś "z grubsza", ale aplikacja może zachować się zupełnie inaczej na serwerze. Ja wczoraj miałem taki problem -> miałem starszą wersję aplikacji zrobioną bez żadnego frameworka itp, bardzo prostą i wykonującą wiele zapytań mysql. Jako, że ciągle wymagała rozwoju i dodawania nowych funkcji w końcu podjąłem decyzję, że odejdę od prowizorki i zrobię to lepiej. Wszystko zostało oparte o Zend_Framework + Propel. Po wgraniu na serwer okazało się, że kluczowa strona aplikacji otwiera się.... 4-5s. Trochę dużo (wersja pierwotna to około 0,5-1 s). Przetestowałem wszystko generatorem obciążeń + xdebugiem i wyszło mi, że nowa wersja jest około 5x wolniejsza od starej. Nie dziwiło mnie to, bo wersja pierwotna była naaaprawdę prosta - dodałem sporo opcji, aplikacja się rozrosła + framework + propel - ogólnie spodziewałem się tego. Xdebugiem wyłapałem wszystkie problemowe kwestie, stuningowałem i różnica zmalała o połowę. O dziwo na serwerze praktycznie brak różnicy. Nadal 4-5 s. na otwarcie najważniejszej strony. Problem okazał się dość kuriozalny - podczas pisania widoku na szybko umieściłem sprawdzanie czy dane zdjęcie istniej za pomocą funkcji fopen (wiem wiem, głupie to było, ale to tylko prowizorka, którą potem miałem poprawić) - lokalnie nie powodowało to problemów, na serwerze po usunięciu tej jednej linijki strona otwiera się w około 0,3-0,7s czyli prawie 10 razy szybcie.... a w dodatku 2 razy szybciej niż wersja pierwotna, która z kolei w testach lokalnych była 3 razy szybsza od wersji rozbudowanej ;-) Oczywiście wiem dlaczego wersja finalna jest szybsza na serwerze od pierwotnej. Kod php jest 2-3 razy dłuższy i bardziej skomplikowany w wersji finalnej, ale za to mniej obciąża bazę danych (mniej zapytań + dużo cachowania) - jak wiadomo bardzo często w hostingach problemem jest wydajność bazy danych więc tu teoretycznie wolniejszy program sprawdza się lepiej. Na localhoscie gdzie całą bazę mam dla siebie nie było to odczuwalne, ale na serwerze docelowym różnica była spora. Problem jednak pozostaje - jak identyfikować wąskie gardła na serwerze? Czy jest jakieś oprogramowanie, które nie wymaga instalacji na serwerze a wystarczy je tylko w skrypcie umieścić? Oczywiście wiem, że można robić mierzenie czasów flagami... ale porównując to z outputem xdebuga analizowanym przez np Kcachegrind to wartość takiej techniki jest nieporównywalnie mniejsza - no i wymaga dużego nakładu pracy. Może ktoś zna lepsze rozwiązania. |
|
|
Wersja Lo-Fi | Aktualny czas: 27.09.2024 - 02:16 |