Zgodnie z życzeniem: "Profilowanie aplikacji".
Zachęcam do udziału w dyskusji

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 ?

W PHP Solution ostatnio ukazał się artykuł na temat benchmarku, można go ściągnąć za darmo Testy wydajności i profilowania aplikacji PHP

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

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.

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.

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.



Poklikanie sobie w profilerze i pobawienie sie w profilowanie swojej malej aplikacji - jak najbardziej. Co innego zabieranie sie za optymalizacje dla samej optymalizacji

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.

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.

Masz może gdzieś pod ręką taki spis/test najpopularniejszych funkcji/etc ?

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.

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

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

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:

[PHP] pobierz, plaintext 
<?php
$array = array('aa', 'bb', 'cc' ....); //tablica z kilkuset elementami
$start = microtime(true);
for($ind = 0; $ind < 1000000; $ind++)
  count($array);
echo('count: ' . (microtime(true) - $start) . '<br />');
 
$start = microtime(true);
for($ind = 0; $ind < 1000000; $ind++)
  sizeof($array);
echo('sizeof: ' . (microtime(true) - $start) . '<br />');
?>
[PHP] pobierz, plaintext 

Wynik testu:
count: 7.9690039157867
sizeof: 7.9895031452179

Potem zmieniłem kolejności wywołań:

[PHP] pobierz, plaintext 
<?php
$array = array('aa', 'bb', 'cc' ....); //tablica z kilkuset elementami
$start = microtime(true);
for($ind = 0; $ind < 1000000; $ind++)
  sizeof($array);
echo('sizeof: ' . (microtime(true) - $start) . '<br />');
 
$start = microtime(true);
for($ind = 0; $ind < 1000000; $ind++)
  count($array);
echo('count: ' . (microtime(true) - $start) . '<br />');
?>
[PHP] pobierz, plaintext 

Wynik był taki:
sizeof: 7.9034969806671
count: 8.0151460170746

Jak widać różnic w zasadzie nie ma.

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 ;]

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

Korzystam z xDebug ale dla zainteresowanych link

Ja też uważam że powinniśmy zwracać uwagę na to jakich funkcji wewnętrznych używamy np.: rand() czy mt_rand(), itd...

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

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.

Właśnie - bardzo często problemem jest wydajność bazy danych, nie samego PHP.
Wydajność bazy można poprawić na co najmniej 2 sposoby:
1. dobrze indeksować dane (większość programistów ma z tym problemy)
2. buforować dane w pamięci

Odnośnie punktu 1 - co byście powiedzieli, gdyby istniało narzędzie, które automatycznie dobiera właściwe indeksy
na podstawie logu zapytań? Istnieje takie coś w Oracle i DB/2, a co gdyby było też coś opensource, np. dla MySQL?
A może takie coś istnieje, ale nie znalazłem?

Krolik - mowisz o wybieraniu sposobu indeksownia typu B-Tree itp ? W MySQLu moze byc problem z czyms takim gdyz np MyISAM obsluguje tylko B-Tree wiec duzego wyboru nie ma.

Nie, mam na myśli generalnie dobór indeksów a nie tylko typu. Zauważ, że indeksy można zakładać na różnych tabelach i różnych kolumnach. W praktyce liczba możliwości nawet w niewielkiej bazie jest przeogromna, a większość ludzi robi to "na czuja", wcale nie podpierając tego fachowa wiedzą.

nie bardzo to widzę...
musiałaby to być złożona klasa która jest klasą abstrakcji bazy...
i musiałaby manipulować zapytaniami bo z tego co wiem jeżeli mamy założony jakiś indeks na kilku kolumnach to liczy się kolejność ich wymienienia w zapytaniu w klauzuli WHERE
wprowadzenie zatem ich w jednym zapytaniu w pewnej kolejności a w drugim odwrotnie... zmuszałoby klasę do tworzenia innego indeksu albo manipulowania zapytaniem... to raczej będzie prowadziło do wielu trudnych do wykrycia błędów
zasadniczo to języki programowania są zrobione po to aby człowiek myślał i kazał wykonywać coś komputerowi
optymalizacja jest zajęciem typowym dla fachowców to człowiek musi wymyślić którędy będzie najlepiej... komputer nie wymyśli algorytmów
pisać klasy pomocnicze powinno się robić raczej do przyspieszenia rozwoju aplikacji, zmniejszajać ilość powtarzalnych czynności
tworzenie różnorodnych indeksów w celu maksymalnego wykorzystania zasobów jest raczej pracą twórczą niż odtwórczą...

Zimi, nie pytałem, czy to się da zrobić, tylko czy coś takiego byłoby potrzebne. Sądząc po tym, co napisałeś o optymalizacji zapytań - utwierdza mnie w przekonaniu, że jest potrzebne.

Mianowicie mijasz się z prawdą twierdząc, że indeksowanie wymaga zmiany zapytań. Kolejność w WHERE może być dowolna i nie ma nic do kolejności indeksów. Systemy RDBMS, nawet te najbardziej prymitywne, traktują WHERE jako ZBIÓR warunków i kolejność występowania warunków połaczonych ANDem czy ORem nie ma znaczenia (te opreratory sa przemienne). Jedynie ma znaczenie kolejność kolumn w indeksach wielokolumnowych, ale to indeksy dobiera się do zapytań, a nie na odwrót.

Odnośnie tego, że musiała by być to złożona klasa abstrakcji: i tak i nie. To że złożona, to jest oczywiste, problem prosty nie jest. Nikt nie mówił że ma być łatwo. Tyle, że to raczej cały system a nie pojedyncza klasa. No i wcale nie musi być to coś pomiędzy aplikacją PHP a bazą danych. Wystarczy osobny program, który ma dostęp do bazy danych i logów zapytań (w MySQL można go włączyć). Taki demon wspomagający pracę admina bazy. BTW: raczej nie wyobrażam sobie implementowania tego w PHP, ze względu na zbyt niską wydajność, tylko raczej w C++ lub Javie, ale to sprawa drugorzędna i dla użytkowników nie mająca większego znaczenia.


Hehe, a kompilatory to myślałeś że co robią? A optymalizatory zapytań w RDBMS? W serwerowni siedzi człowiek i każde zapytanie SELECT ręcznie optymalizuje?


Wymyśli - złe słowo, ale dobierze i sparametryzuje - zdecydowanie TAK.


Słyszałeś o uczeniu maszynowym? AI?

Jak dla mnie sam pomysł aplikacji jest bardzo dobry. Sam mam raczej małą wiedzę o działaniu baz danych i indeksy dobieram "zdroworozsądkowo" - bardzo fajnie byłoby aby jakiś program zrobiła analizę co gdzie i jak umieścić. Plus tego taki, że programista nie zawsze ma dobre rozeznanie co i jak jest obciążone w bazie - może mieć inną wizję a logi pokażą co innego. Dla przykładu używając ORM'ów czasami można się zdziwić zapytaniami jakie są generowane. Oczywiście można powiedzieć dobry programista kontroluje wszystko i wie jak działa jego system, ale z ręką na sercu ilu z was przegląda wszystko dokładnie od a do z.

Program nie ma żadnych "przekonań" na początku i całą analizę oparłby na logach.

Dla początkujących i średnio zaawansowanych narzędzie wydaje mi się bardzo dobre, a i dla zaawansowanych pewnie przedstawiałoby jakąś wartość może nie jako "decydent" a bardziej jako "doradca".

nie mam wiedzy absolutnej na temat optymalizacji zapytań... co więcej jest ona dość nikła, dopiero wydrukowałem sobie z manuala MySQL co ciekawego napisali o optymalizacji i będę sobie to powoli przyswajał
więc teraz aby się upewnić czy się rozumiemy
załóżmy że mamy indeks na 3 polach w kolejności a, b, c
a następnie zapytanie:

i wtedy nasz indeks będzie działał, i teraz drugie zapytanie:

i tutaj nasz indeks już nic nie da...
jeśli mam rację to:

jednak wymaga to zmiany zapytania gdyż jedynie o ten przypadek mi chodziło... i sytuacje w której niczego nieświadomy użytkownik pomyli sobie kolejność kolumn albo nawet nie będzie wiedział że to ma znaczenie i zrobi odwrotnie "bo tak"

w tym momencie Twój projekt staje się jedynie rozwiązaniem połowicznym... gdyż projekt robisz jak rozumiem docelowo dla amatorów którzy nie mają pojęcia o indeksacji i ogólnie optymalizacji zapytań... jeśli tak to indeksy wielokolumnowe niewątpliwie stoją już na wyższym poziomie, a generalnie idea powinna być "trudne uprościć" a nie "łatwe uprościć"(to ew. przy okazji), przy jednokolumnowych indeksach (przy ich tworzeniu) to na dobrą sprawę "widzę że przez to polę wyszukuję często dane" => "robię indeks" (no ew. jeszcze kilka reguł, ale ta w sumie najprostsza), nie ma w tym zbyt wielkiej filozofii, a przynajmniej ja (zaznaczam że mam braki w tej dziedzinie, jak się wymądrzam to przepraszam i poprawcie mnie) nie widzę w tym większej filozofii, choć przydatnym narzędziem będą logi zapytań, ile czasu zajmuje zapytanie, tudzież stosunek czasu do ilości rekordów w tabeli bądź inne statystyki i analiza zapytania na poziomie abstrakcji bazy aby z klauzul WHERE, ORDER BY, GROUP BY, HAVING i chyba jeszcze jakiś wydobywał nazwy kolumn i weryfikował czy na danym polu jest indeks czy nie, oczywiście niekoniecznie w momencie wykonywania każdego zapytania

poza tym niezależnie od indeksów wielokolumnowych podejrzewam że optymalizacja może mieć również związek z kolejnością w klauzuli WHERE, gdyż prawdopodobnie (choć może i nie) zachodzi tam "skracanie" warunku (nie pamiętam czy miało to jakąś fachową nazwę, a jeśli tak to jaką...), a czytanie warunku zachodzi z tego co wiem od lewej do prawej
chodzi o to że jeśli będziemy mieli np.

1=0 oczywiście nie ma być docelowym warunkiem, chodzi mi o to że programista przy pisaniu kodu ma świadomość, że coś często będzie fałszem lub prawdą i to wstawia na "pierwsze pozycje"
serwer SQL prawdopodobnie wiersz odpuści już po pierwszym warunku 1=0 gdyż z góry będzie fałszywy bezwzględu jakie wartości przybiorą kolejne zdania logiczne
natomiast gdy zamienimy kolejność:

serwer może sporo danych przewertować, stracić dużo zasobów a i tak w końcu wyjdzie że dany wiersz nas nie interesuję...
w tego typu przypadkach Twoja klasa/funkcja/program/cokolwiek nie będzie miało już wiele do gadania bo są to dość skomplikowane zagadnienia zresztą to była tylko taka dygresja o znaczeniu kolejności
no ale w sumie chyba wszystko można zaprogramować

szczerze mówiąc nie wiem, a nawet nie wiedziałem o ich istnieniu choć ich istnienie wydaję się być zrozumiałe... nie mniej podejrzewam że mają minimalne znaczenie dla efektywności zapytań, podobnie jak w kodach PHP, podobno Zend Optimizer zamienia $d++ na ++$d bo jest szybsze (nie wiem czy to prawda, tak gdzieś przeczytałem... mało ważne) jednak znaczenie takiej optymalizacji przy skopanym algrotymie jest tak nikłe że nawet niewarto o nim wspominać

tak słyszałem, choć nie mam chwilowo pojęcia w jaki sposób działa (nie próbowałem się nawet nad tym bardziej zastanawiać), nie douczałem się w tej materii...
nie mniej gdy o tym wspomniałeś odbieram wrażenie że to przerost formy nad treścią...
i znacznie lepiej dla każdego kto potrzebuję optymalizacji będzie przeczytanie kilku stron o tym zagadnieniu niż skorzystaniu z takiej aplikacji, przynajmniej chwilowo taka moja opinia


a więc potrzebujesz logów a niekoniecznie takiej aplikacji, a resztę robisz dalej "zdroworozsądkowo", a taka aplikacja może się zacząć "wymądrzać" co różne programy mają do siebie... co zaczyna być działaniem szkodliwym

Jeśli tak rzeczywiście jest w MySQL, to gratuluję jego twórcom lamerstwa
To, że są słabi w te klocki, to wiedziałem, ale żeby aż tak, to się trzeba mocno wysilić.
Dlatego niezbyt Ci wierzę Ci i jeszcze to sprawdzę. W normalnym systemie oba zapytania użyją indeksu - nie ma żadnego przeciwskazania, żeby tak nie było.


Przy tym podejściu miałbyś 5 razy tyle indeksów co potrzeba. Czyli rozmiar bazy większy i niepotrzebnie spowolniony update/insert.

Dalszej części postu komentował nie będę tylko polecę Ci lekturę porządnej książki o optymalizacji zapytań, konstrukcji RDBMS np. z serii Klasyka informatyki "Implementacja systemów baz danych". Mam nieodparte wrażenie, że Twoja wiedza na ten temat kłada się głównie z tego "jak myślisz, że RDBMS działa" a nie jak jest zrobiony w rzeczywistości. Poza tym wzorowanie się w tym zakresie na MySQL to zły pomysł.



Widać.



Ok, przyjąłem tę opinię do wiadomości.

Dodam, że optymalizacja pewnej niewielkiej bazy danych (raptem 30 tabel) u nas w firmie zajęła metodą "analizy logów i EXPLAIN" jednemu wykwalifikowanemu adminowi 4 dni. Może i mało, ale należy pamiętać,że taką optymalizację robi się co jakiś czas, bo aplikacja / dane się zmieniają i że to była raptem jedna mała baza danych. A co gdybyśmy byli firmą hostingową i hostowali 100 aplikacji? Myślisz, że ktoś miałby czas bawić się i sprawdzać, czy jakiś lamer nie walnął selecta bez indeksu, który jedzie po tabeli na milion rekordów? Ten program nie ma być lepszy od wykwalifikowanego DBA, ale ma przede wszystkim zaoszczędzić czas. Podłączasz do bazy danych, wskazujesz log, klikasz jeden guzik i za 5 minut masz zestaw "prawie" optymalnych indeksów.

I jeszcze takie małe, łatwe pytanie kontrolne. Jakie indeksy są najlepsze w tym przypadku:

SELECT nazwa_produktu, cena, opis FROM produkty WHERE cena < 5000 AND miasto = 'Krakow' ORDER BY cena LIMIT 10;

W bazie są produkty o cenach od 10 do 10000, z całego kraju. To jest klasyczne pytanie na jakie musi odpowiedzieć każdy DBA. Odpowiedź trzeba uzasadnić.

Krolik to pytanie dotyczy Postgres-a czy MySQLa ?

Miasta raczej bym trzymal w osobnej tabeli bo porownywanie stringow nie nalezy do najszybszych z tego co wiem. Gdyby mialo byc tak jak mowisz to na miasto nie oplacalo by sie zakladac indeksu jakoze dane powtarzaby sie. Krolik - dla MySQLa twoje pytanie nie ma sensu pozatym Bo i tak tylko zwykly index mozna zalozyc. Primay i unique odpada no chyba ze sie myle ? Co do Postgres-a moja wiedza jest obecnie niewielka tak wiec nie bede nic pisal Ale chetnie poslucham co w trawie piszczy

Do do tego indeksowania po 3 polach. MySQL do wersji 5.0 korzysta tylko z jednego indeksu na danej tabeli w zapytaniu niestety Od wersji 5.0 dokonal sie postep. Aby wykorzystac indeksowanie na 3 polach czasem lepiej bylo tworzyc zapytanie korzystajac z UNION

Pytanie dotyczy dowolnego RDBMS. I nie chodzi mi tylko o jaki typ indeksu (w MySQL jest tylko B+ drzewo), ale na których (której) kolumnie. Są co najmniej 4 możliwości: tylko na cenie, tylko na mieście, 2 osobne indeksy na cenie i mieście, jeden 2-kolumnowy indeks (cena, miasto). I jeszcze zerowa możliwość: brak indeksu.



Powtarzanie się danych nie jest przeciwwskazaniem dla indeksu, o ile nie jest UNIQUE. Przeciwsskazaniem może być natomiast zbyt mała selektywność warunków (czyli np. gdy się zbyt wiele powtarza) - w MyISAM niestety nie ma indeksów sklastrowanych, więc wtedy często skan sekwencyjny bywa lepszy niż użycie indeksu.

Indeksy wielokolumnowe są obsługiwane w wersji zarówno 4 jak i 5 MySQL. Tylko zauważ różnicę: użycie JEDNEGO wielokolumnowego indeksu, a użycie DWÓCH różnych indeksów. MySQL 5 potrafi użyć 2 różnych indeksów i dokonać unii (jeśli był warunek OR) albo przecięcia (dla AND) - tego MySQL 4 nie potrafił.

Padła informacja o sposobie dobierania indeksow i porownie do ORACLE. Wiec tak to odbywa sie w nastepujacy sposob, juz pomijajac sam fakt prepare i weryfikacji obiektow bazy danych. Optymalizator wylicza sobie najlpesza metode polaczenia zapytania i tytaj nie wchodzi w gre tylko i wylacznie dobor indeksow ale rowniez kolejnosc tabel w from, jakie pola beda brane pod uwage co kiedy ma robic, liczba obliczeniami zajmuje sie optymalizator w bazie ORACLE jest to od 10g kilka zmian doszlo w 11. Co do MySQLa czy PG no to wiadomo. Ogolnie wiekszosc baz wykorzystuje optymalizator regulowy.

@Krolik pisales o wilu indeksach i roznym wykorzystaniu przez MySQL5. Nieraz tak jest nieraz nie, widac to po EXPLAIN. Optymalizator to tylko zbior regul ktore ma wykonywac i na podstawie indeksow i innych obiektow podejmowac decyzje jak dane sa wyciagane. Nie wiem jak to jest z MySQLem do konca ale w takich przypadkach powinny być HINTy dla optylamizatora takie wskazówki w komentarzu jak sie ma zachować.

@Krolik - dobre pytanie.
Niby takie proste, a jednak musiałem aż sprawdzić, by się upewnić, jak to powinno wyglądać.

I niestety - już tu widać, że co baza to zwyczaj.

MySQL i PG zachowują się pod tym względem bowiem nieco inaczej.

W każdym z przypadków najwięcej sensu ma oczywiście index miasto, które to pole będzie zawierać najmniejszą ilość unikalnych danych. Dzięki temu też wyszukanie rekordów spełniających określonych warunek będzie bardzo szybkie.

Niestety - cena jest znacznie bliższa wartości losowej, stąd też tworzenie na niej indexu w przypadku takiego zapytania nie ma zbyt wielkiej wartości, gdyż jego przeszukanie jest równoznaczne z przeszukaniem wszystkich pól w bazie, z chyba właśnie z tego powodu obie bazy nie będą chciały z niego korzystać.

Co ciekawe - w przypadku PG sens może mieć index miasto_cena, który (w przypadku mojej testowej bazy - 100 tys rekordów) o połowę przyśpieszył to zapytanie (niż tylko index miasto). MySql nie potrafił skorzystać z takiego indexu w tym zapytaniu.
Trzeba pamiętać jednak o tym, że będzie to naprawdę potężny index.

ps. Czy naprawdę sądzisz, że automat analizujący logi jest w stanie rozwiązać takie problem za mnie?

pps. Swoją drogą - jakiś mechanizm do analizy logów bazy tworzy depesz ( depesz.com )

Pytanie było specjalnie takie, żeby nie było jednoznacznej odpowiedzi. Słabsze systemy najprawdopodobniej wybiorą mniejsze zło, tj. tak jak napisał DevV:

LIMIT (1, 10)
|
+ SORT (cena)
|
+ INDEX_SCAN (miasto = 'Krakow' AND cena < 5000) <-- indeks na (miasto, cena)


Albo tak (nieco gorzej):


LIMIT (1, 10)
|
+ SORT (cena)
|
+ FILTER (cena < 5000)
|
+ INDEX_SCAN (miasto = 'Krakow') <--- indeks tylko na (miasto)


Wszystko zależy trochę od rozkładu wartości w bazie, ale można się spodziewać, że ponieważ Kraków jest dużym miastem,
to warunek miasto = Kraków ma słabą selektywność (załóżmy 20%), podobnie warunek na cenę też ma b. słabą selektywność (ok. 50%, jeśli rozkład jest równomierny). W tej sytuacji najlepszy byłby indeks klastrujący na cena, żeby uniknąć sortowania:

LIMIT(1, 10)
|
+ FILTER (miasto = 'Krakow')
|
INDEX SCAN (cena < 5000) <--- indeks tylko na (cena)

Niezależnie od sumarycznej liczby rekordów ten plan wymaga odczytania średnio raptem ok. 50 rekordów tabeli, ze względu na możliwość wykonania iteracyjnego i LIMIT, podczas gdy poprzednie plany czytają odpowiednio 10% * liczba_rekordów (pierwszy) i 20% * liczba_rekordów (drugi) i oba sortują 10% rekordów całej tabeli. Pewnie DB/2 lub Oracle potrafiłoby znaleźć ten plan bez hintów, ale muszę sprawdzić. Jeśli optymalizator nie zauważy, że można wyeliminować sortowanie oraz że można przerwać skanowanie po osiągnięciu 10 rekordów wyniku, ten plan automatycznie staje się prawie najgorszym z możliwych.

To tyle omówienia zadania. Zadanie miało na celu tylko zilustrowanie, że problem wprawdzie prosty nie jest i rozwiązanie mocno zależny od jakości optymalizatora bazy danych, to nie jest wcale żadną tajemnicą, co potrafią robić różne optymalizatory i program może to uwzględniać. Wydaje mi się, że nawet w niektórych przypadkach może to zrobić lepiej niż człowiek - kto z Was zna szczegóły działania optymalizatora MySQL czy PostgreSQL? Raczej stosuje się metodę "prób i błędów" a nie podejście naukowe. Podobnie program bez trudu potrafi oszacować selektywność warunków i zrobić podobną analizę, którą przedstawiłem przy okazji zadania.

BTW. Istnieje taki projekt dla DB/2 i działa nieźle. Dla MySQLa byłoby dużo prosciej, bo on potrafi zdecydowanie mniej (ma regułowy optymalizator -> łatwo się go przewiduje). Ponadto nie zalezy mi na tym, by ten program dawał zawsze najlepszy możliwy wynik, ale żeby raczej stanowił pomoc w "zgrubnym" dobraniu większości indeksów, w bardzo krótkim czasie.