Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu sql Kanał ATOM (tag: sql)

Autor wpisu: SongoQ, dodany: 04.02.2009 07:46, tagi: php, apache, sql

Przeprowadziłem kilka testów szybkości odczytu z pliku i tabel typu: MEMORY, MyISAM.

Jak był przeprowadzany test:

Test przeprowadzałem na Ubuntu Dapper (apache2, php5.1.x, MySQL 5.0.22) na laptopie, więc wiele rzeczy mogło wpłynąć na na nieprawidłowość testów.

Test podzieliłem na kilka etapów:

  • z włączonym cache zapytań
  • z wyłączonym cache zapytań
  • z pomiarem połączenia z bazą danych

Odnośnie ilości wywołań testu, to był wykonywany 1000 razy, liczone były pojedyńcze czasy testu, a następnie sumowane i liczona z tego średnia testu. Jako danych testowych użyłem wygenerowanego ciągu znaków o długości około 65 KB.

Wyniki:

Odczyt z pliku:

Do odczytu z pliku użyłem funkcji: file_get_contents() Średni czas odczytu jaki uzyskałem to: 0.000357507705688 (szczegółowe informacje)

Odczyt z bazy danych:

Do odczytu z bazy użyłem funkcji mysql_* (połączenie, wybór bazy, wykonanie zapytanie i zwrócenie rekordu). Tabela zawierała 1 rekord z id i polem w którym był zapisany taki sam ciąg znaków jak w przypadku pliku. Dlaczego nie więcej? Chciałem wyeliminować czas jaki będzie potrzebny na przeliczenie jaki rekord ma zostać zwrócony.

Wyłączony zapis cache w MySQL i czas połączenia z bazą pominięty:

Tabela MyISAM - średni czas to: 0.00516110825539 (szczegółowe informacje) Tabela MEMORY - średni czas to: 0.00368802952766 (szczegółowe informacje)

Widać, że odczyt z pliku ma przewagę nad odczytem z bazy danych, a czasy odczytu z tabel typu MyISAM i MEMORY są bardzo do siebie zbliżone.

Włączony zapis cache w MySQL i czas połączenia z bazą pominięty:

Tabela MyISAM - średni czas to: 0.00179107260704 (szczegółowe informacje)

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: SongoQ, dodany: 02.02.2009 21:23, tagi: php, sql

Na forum php.pl pojawił się post z pytaniem czy zastosowanie prepared statements wpływa na wydajność zapytań.

Troszeczkę teorii:

Jak to wygląda od strony ORACLE:

Zanim dane zostaną zwrócone z bazy danych, po odebraniu odpowiedniego kodu baza danych Oracle musi wykonać określone czynności:

  • tworzenie kursora
  • proces parsowania zapytania jeśli nie istnieje w obszarze wspólnym. Na proces ten również wchodzi kilka etapów:
    • analiza zapytania - sprawdzenie czy zapytanie składniowo jest poprawne
    • sprawdzenie odwołań do obiektów
    • sprawdzenie uprawnień
    • modyfikacja zapytania, w celu uzyskania zapytania równoważnemu danemu, ale wykonywanemu efektywniej
    • przygotowanie planów wykonania na podstawie statystyk, wskazówek
    • wybranie najlepszego planu wykonania (najmniejszy koszt wykonania)
    • zapisanie do obszaru wspólnego

    Wykorzystanie wcześniejszego zapytania jest możliwe tylko wtedy, kiedy:

    • tekst zapytania jest taki sam (wchodzą w to również komentarze i białe znaki),
    • polecenie musi odwoływać sie do tych samych obiektów w bazie danych,
    • zmienne wiązane muszą się tak samo nazywać i być tego samego typu.
  • przygotowanie zapytania
  • podwiązanie zmiennych
  • wykonanie zapytania
  • zwrócenie rekordów do użytkownika

Jeśli do bazy danych jest wysyłane takie samo zapytanie proces parowania nie jest wykonywany, przez co wydajność wzrasta bo pewna czść operacji jest pomijana.

Czy zawsze stosować takie rozwiązanie?

Są przypadki zapytań dla których najlepszy plan pierwszego wykonania dla pewnych parametrów jest nieoptymalny i zaleca się nie stosowanie zmiennych wiązanych.

MySQL:

Jeśli chodzi o bazę danych MySQL mechanizmy nie są aż tak bardzo zaawansowane ale pewne rzeczy są zaimplementowane.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: stormfly, dodany: 25.10.2008 11:29, tagi: sql

Czas płynie nieubłaganie, a jakiekolwiek nadzieje, że będzie trochę więcej czasu przy skończeniu kolejnego projektu rozwijają się bardzo szybko. Obiecałem sobie jednak, że postaram się umieszczać przynajmniej jeden wpis na miesiąc, aby mój blog nie podzielił losu innych...
Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.