Poradnik e-Commerce / e-Biznes

PrestaShop - prędkość ma znaczenie (7)

Narastająca ilość zbieranych przez PrestaShop danych statystycznych powoduje spowolnienie działania sklepu internetowego. Z czasem coraz bardziej odczuwalne. Na szczęście bardzo popularna baza danych MySQL oferuje slow logi - logi zapytań, które wykonują się powoli. Ich analiza pozwala wykryć wąskie gardła i wprowadzić poprawki przyspieszające działanie PrestaShop.

Powody długiego wykonywania zapytań SQL to przede wszystkim:

• duża ilość danych (rekordów) w tabeli(-lach)
  lub
• nieoptymalnie przygotowane zapytanie(-a) SQL.

1) PrestaShop - działa wolno, bo gromadzi dużo danych w tabelach

Przykładowe fragmenty slow logów (poniżej) pokazują, że dwa zapytania wykonują się bardzo długo - ze względu na dużą ilość rekordów tabelach. W pierwszym przypadku jest to zapytanie SELECT, które działa na tabeli zawierającej ponad 85 tysięcy rekordów. Drugie zapytanie to INSERT do równie rozbudowanej tabeli - także widać długi czas wykonania.

# Query_time: 3.509795  Lock_time: 0.000056 Rows_sent: 0  Rows_examined: 85009
SET timestamp=1413283554;
SELECT `id_connections` FROM `ps_connections` c
...

# Query_time: 2.727986  Lock_time: 0.000060 Rows_sent: 0  Rows_examined: 0
SET timestamp=1413092268;
INSERT INTO `ps_connections_source` (`id_connections`,`http_referer`,`request_uri`,`keywords`,`date_add`) VALUES
...

W systemie PrestaShop tabele

• ps_connections
• ps_connections_source
• ps_guest
  
• ...
  

zbierają dużą ilość statystycznych informacji o odwiedzających. Nawet jeśli potrzebujesz danych historycznych sprzed 3 lat, to niekoniecznie muszą one się znajdować w tabelach, których używa sklep. W tabelach można zostawić kilka ostatnich miesięcy. 

Najprostszym sposobem pozbycia się balastu z tabel roboczych jest

• utworzenie ich kopii, np. z ps_connections do ps_connections_kopia1, gdzie znajdzie się cała dotychczasowa zawartość
• usunięcie z ps_connections wpisów starszych niż... (wedle uznania)

Pierwszą operację można przeprowadzić nawet klikając w phpMyAdmin. :)

Druga operacja szybciej i sprawniej przebiegnie z wykorzystaniem prostego zapytania SQL:

DELETE
FROM `nazwabazy`.`ps_connections`
WHERE `date_add` <= '2014-06-01 00:00:00'

Po wykonaniu zobaczysz komunikat, np.

Usuniętych rekordów: 72144. ( Wykonanie zapytania trwało 3.9256 sekund(y) )

Przy zapytaniach wpisywanych ręcznie zalecam dużą ostrożność! Przed usuwaniem rekordów koniecznie SPRAWDŹ CO ZOSTANIE USUNIĘTE:

SELECT *
FROM `nazwabazy`.`ps_connections`
WHERE `date_add` <= '2014-06-01 00:00:00'

Jak widać sprawa jest prosta dla każdego kto zna SQL - to co SELECT * wyświetli to DELETE usunie.

Co zaś pozostanie, można jeszcze przed usuwaniem sprawdzić zamieniając warunek WHERE z "<=" na ">" - jak poniżej:

SELECT *
FROM `nazwabazy`.`ps_connections`
WHERE `date_add` > '2014-06-01 00:00:00'

Uwaga: nie pomyl się, bo sobie skasujesz nie to co trzeba...

Archiwizować dane czy usuwać?

Jeśli uważasz, że dane z poprzednich lat są potrzebne lub kiedyś mogą być potrzebne to archiwizuj je. Jedynym ograniczeniem jest ilość miejsca, które zajmują. Możesz je archiwizować w bazie danych - tej samej lub innej. Co jest wygodne. Lub zgrywać do plików i usuwać z bazy.

Niektórzy też mogą chcieć zautomatyzować cykliczne przenoszenie danych do tabeli archiwalnej. Np. pierwszego dnia miesiąca wszystkie rekordy starsze niż 6 miesięcy są przenoszone do tabeli z archiwum. Dzięki temu robocza tabela się opróżnia i nie spowalnia systemu/sklepu.

Nic nie stoi na przeszkodzie aby niepotrzebne dane po prostu trwale usuwać. Jeśli wiesz, że do nich nie wrócisz i nie będą potrzebne - usuwaj.

Optymalizować tabele MyISAM

Baza MySQL z tabelami MyISAM podczas działania, a w szczególności przy wstawianiu i usuwaniu z tabel danych (rekordów) można powiedzieć, że z czasem się "fragmentuje" i potrzebna jest "defragmentacja". Za pomocą phpMyAdmin można prosto sprawdzić, czy tabela wymaga optymalizacji. Jeśli przy tabelach typu MyISAM widać niezerowy "Nadmiar" (overhead) to należy przeprowadzić optymalizację.

Tabelę MyISAM optymalizuje się poleceniem SQL

OPTIMIZE TABLE nazwatabeli

I to wszystko. Tabela zostaje przebudowana i zoptymalizowana. Zapytania będą działać szybciej.

Natomiast tabele oparte o mechanizm InnoDB zwykle nie wymagają optymalizacji. Przy InnoDB sam silnik bazy danych dba o to, aby struktura tabeli była możliwie jak najbardziej optymalna. W każdym bądź razie radzi sobie z "defragmentacją" dużo lepiej niż w przypadku MyISAM. Optymalizacja tabel InnoDB przebiega identycznie.

W systemie PrestaShop sporadycznie pojawiają się tabele MyISAM - zwykle pochodzą z dodatkowych modułów. Warto jednak o tym pamiętać, gdyż taki moduł właśnie może się okazać wąskim gardłem dla wydajności sklepu internetowego.

Dokumentacja MySQL 5.5 - optymalizacja tabel:

• http://dev.mysql.com/doc/refman/5.5/en/optimize-table.html
• http://dev.mysql.com/doc/refman/5.5/en/optimizing-myisam.html
• http://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-storage-layout.html

2) PrestaShop - działa wolno, bo zapytania SQL są źle napisane

Problem, który można wykryć za pomocą slow-logów dotyczy zwykle dodatkowych modułów i komponentów. PrestaShop sam w sobie jest dość dobrze napisany przez tworzących go programistów. Natomiast rożne darmowe a nawet płatne dodatki już niekoniecznie wolne są od błędów. Slow-logi dają odpowiedź, czy są takie zapytania.

Jeśli są i dotyczą odczytu danych to najprostszą metodą jest modyfikacja kodu SQL z "SELECT ...." na "SELECT SQL_CACHE ....". Takie działanie na często wykonywanych zapytaniach może dać wzrost wydajnościowy. Czasem nie da - gdy zapytanie nie jest często wykonywane lub ze względu na konfigurację bazy danych (domyślnie włączone cache-owanie zapytań SQL - co jest częstą praktyką wśród firm hostingowych - a to dobrze!)

Wyższy poziom wtajemniczenia, to modyfikacja, często skomplikowanych, zapytań do bazy danych, które dadzą ten sam wynik mniej obciążając jednocześnie serwer. Ta część prac (programistycznych) wykracza już znacznie za zakres tego artykułu.

* * *

Pamiętaj: Im szybciej - tym lepiej. Im szybciej ładują się podstrony sklepu internetowego - tym lepiej. Potencjalny klient może porzucić przeglądanie sklepu, gdy ten działa zbyt wolno. Szybkość więc jest równoznaczna z wygodą potencjalnego klienta (to jeden, nie jedyny, czynnik - ale na tym się skupimy w tej części). Algorytmy Google także biorą pod uwagę szybkość działania serwisu www czy sklepu internetowego. Należy więc dbać o to, aby serwis internetowy działał możliwie najszybciej - zwłaszcza, jeśli to sklep internetowy, który przeglądają klienci. Nie skazuj ich na powolnie działający sklep, gdzie strony produktów ładują się poooowoooooliiiii...

O tym, dlaczego tracisz klientów z powodu wolno działającego serwisu internetowego możesz przeczytać tutaj.

• < Poprz.
• Nast. >