![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) ![]() ![]() |
Witam, ostatnio postanowilem sie zajac cachowaniem zapytan z bd. I tak pomalutku stworzylem swoja klase do cachowania/odczytywania zapytan z PostgreSQL. Klasa po malych przerobkach bedzie dzialac rowniez z MySQL.
Na poczatek, co by nie byc posadzony o plagiat (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) od razu przyznam sie ze korzystalem z rozwiazania mike_mecha (http://php.nq.pl/index.php?showtopic=22487&hl=cache) - ale oczywiscie tyko pogladowo (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) Na poczatek moze diagram mojego rozwiazania Diagram klas (uml znam slabo wiec pewnie sa bledy w diagramie jesli chodzi o oznaczenie relacji) Co do kodu to znajduje sie on tutaj: (podaje linki bo kodu jest za duzo na wklejanie) Klasa DB -glowna klasa bazy danych Db_result - abstrakcyjna klasa wyniku zapytania Db_Result_orig - wynik zapytania wykonanego z bazy Db_result_cache - wynik zapytania wykonanego z cachu (lub z bazy z pozniejszym cachowaniem) GenericException - Rozszerzenie klasy Exception o zapis wyjatkow do loga PGException - klasa wyjatku bazy danych Klasy dodatkowo korzystaja z kilku stalych (np. connection string, sciezka do katalogu z cachem itp), ktore trzymam w osobnym pliku -> gdyby ktos chcial przetestowac na zywo dzialanie klasy to trzeba odpowiednie pliki wygenerowac wraz ze stalymi. Najwazniejsze cechy moich klas to: - cachowanie zapytan do pliku tekstowego / odczytywanie zapytan z takiego cachu - system obslugi wyjatkow z zapisem bledow do logow - mozliwosc iterowania wyniku - zastsowany interfejs iteratora Jako ze jestem poczatkujacy prosze o ocene kazdego aspektu, ktory przyjdzie wam do glowy - poczynajac od kodu a na organizacji projektu konczac - kazda rada / wytkniecie bledu mile widziane. Przykladowe zastosowanie
Ten post edytował athabus 15.06.2006, 19:28:22 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) ![]() ![]() |
mariuszn3Dzieki za przeprowadzenie testow. Mysle ze wyniki z uzyciem mojej klasy bylyby podobne - uzylem podobneg rozwiazania jak mike_mech tyle ze dodalem kilka funkcjonalnosci.
Chetnie porownalbym wyniki na moim kompie uzywajac MySQL'a ale niestety nie mam go zainstalowanego (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) (ostatnio korzystam z PG i jakos nie zainstalowalem). Nie wiem czy PG ma cachowanie wynikow - recznie go w kazdym razie nie instalowalem - uzywam wersji "prosto z pudelka". Teraz tylko zastanawia mnie w jaki sposob mySQL cachuje wyniki. W pamięci operacyjnej? Jesli tak to musza one byc nietrwale. Na pewno daja spore rezultaty przy czesto wykonywanych zapytaniach, ale przy rzadziej sie powtarzajacych (dajmy na to raz na godzine) ten mechanizm sie nie sprawdzi tak dobrze. (wszystko co tu pisze to moje przemyslenia nie poparte testami). Kwestia teraz proporcji zapytan czesto sie powtarzajacych do tych rzadziej sie powtarzajacych -> duzo niewiadomych (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) Wszystko to sklania mnie do napisania dodatkowej klasy do testowania czasow zapytan + dostosowanie jej do mySQL. Fajnie byloby sprawdzic jaki procent zapytan stanowia zapytania cyklicznie sie powtarzajace. Mysle ze w warunkach "produkcyjnych" moja klasa da pozytywne rezultaty - w ostatecznosci ograniczy obciazenie bazy - ale Twoje testy daja mi duzo do myslenia. Co do ustalenia polacznenia dopiero przed wywolaniem zapytania korzystajacego z bazy - to swiadomie porzucilem ten pomysl. Sytuacja wygenerowania strony bez zadnego zapytania do bazy (pisze ten sterownik pod katem sklepu internetowego, ktory chce sobie napisac) jest raczej malo prawdopodobna wiec polacznie i tak bedzie trzeba ustanowic. |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 352 Pomógł: 0 Dołączył: 22.01.2006 Ostrzeżenie: (0%) ![]() ![]() |
Teraz tylko zastanawia mnie w jaki sposob mySQL cachuje wyniki. W pamięci operacyjnej? Jesli tak to musza one byc nietrwale. Na pewno daja spore rezultaty przy czesto wykonywanych zapytaniach, ale przy rzadziej sie powtarzajacych (dajmy na to raz na godzine) ten mechanizm sie nie sprawdzi tak dobrze. (wszystko co tu pisze to moje przemyslenia nie poparte testami). Kwestia teraz proporcji zapytan czesto sie powtarzajacych do tych rzadziej sie powtarzajacych -> duzo niewiadomych (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) Na pewno MySQL cache'uje wyniki w pamięci operacyjnej, dzięki temu ma bardzo szybki dostęp dodanych, czemu uważasz, że muszą być one nie trwałe? Zwróć uwagę, że serwer na którym stoi strona restartuje się może kilka razy w roku a dane w pamięci operacyjnej nie są jak atrament sympatyczny, który po godzinie sam znika. Według mnie pamięć operacyjna to zdecydowanie najlepsze rozwiązanie. Co do tego jak działa od środka, no to nie studiowałem tego.. ale podejrzewam, że ogólna zasada jest prosta. W ustawieniach serwera ustawiasz wielkość cache'u.. w manualu pisze, że domyślnie jest to wartość 0 (!) co na starcie wykluczałoby cache'owanie ale mam wrażenie, że w domyślnym pliku konfiguracyjnym, który wgrywa się wraz z instalacją serwera jest wpisana dodatnia wartość, ja bardzo w swojej konfiguracji nie grzebalem i mam wpisane 8MB. Serwer zapełnia ten cache póki może a jak się okazuje, że zbliża się do limitu wtedy nadpisuje te najstarsze zapytania, to tylko moje przypuszczenie. Wierzę, że jest to bardzo logicznie rozwiązane w końcu nie takie głowy nad tym siedziały. Z dodatkowych rzeczy, jest ustawienie, które ustala powyżej jakiej wielkości nie cache'ować odpowiedzi (domyślnie 1MB), jak i też możesz ustawić cache'owanie na zawołanie.. ale wtedy każde zapytanie, które życzysz sobie aby MySQL cache'ował musisz zacząć poprzez 'SELECT SQL_CACHE' też można w drugą stronę, ustawić aby cache'ował wszystkie (tak jest domyślnie) a jeśli chcesz uniknąć cache'owania w jakimś zapytaniu zaczynasz zapytanie poprzez 'SELECT SQL_NO_CACHE'. W manualu też mocno zwracają uwagę, że w przypadku mnogości różnych małych nie powtarzających się zapytań tak naprawdę cache'owanie może bardziej popsuć wydajność niż ją poprawić.. ale to jest logiczne i dotyczy jakiegokolwiek systemu cache'owania... aby cache'owanie się zwróciło zapytania muszą się powtarzać, to się rozumie samo przez sie. Ten post edytował mariuszn3 16.06.2006, 23:36:43 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 2.10.2025 - 21:17 |