Czego potrzebuje presta by działać szybko

[athbus 106]

Witam,

 

wdrażam właśnie u siebie w sklepie Prestę, która ma zastąpić nasze stare wysłużone rozwiązanie.

 

Ogólnie wiadomo, że Prestashop szybkością nie grzeszy, ale chciałbym uzyskać w miarę sprawne działanie tego skryptu. Obecnie stoi na VPS w IQ.pl/provps.pl (http://provps.pl/managed_vps.vps - oferta managed 1). Po modyfikacjach ustawień serwera udało się zejść do czasu odpowiedzi serwera rzędu 2-3s, czyli powiedzmy nie ma tragedii, ale też nie jest dobrze.

 

Zatem pytanie czego Prestashop potrzebuje aby działać "jak żyleta", tj. zejść z czasem odpowiedzi serwera poniżej 0,8-1s?

 

Sklep ma około 5.000 produktów (10.000 kombianacji) - kombinacje proste w oparciu o 1 atrybut, żadnych wieloatrybutowych. Sam sklep ma około 300-400k wyświetleń stron w skali miesiąca, czyli nic wielkiego.

 

 

[xorg 693]

 

 

do czasu odpowiedzi serwera rzędu 2-3s

Chyba nie wiesz co piszesz

[athbus 106]

Dlaczego? Nie wiem czy używam prawidłowej terminologii, ale chodzi mi o wartość podawaną przez Page Speed Insights, czyli czas od żądania do odpowiedzi serwera (bez pobierania grafiki etc). Czyli jeśli dobrze rozumiem jest to czas potrzebny od wysłania zapytania do przetworzenia go przez serwer i zwrócenia wyników. Obecnie ta wartość spadła z 8s do 2-3s, ale już w zauważyłem 2 kolejne błędy wykonawcy.

[Gość Rafiki]

1. uzyć nginx + php-fpm (pod php 5.6 ładnie chodzi a tymbardziej z opcache), mysql można zamienic na percone

2. właczyć cacheowanie oparte o mysql + cacheowanie plikow css, js (minimalizacje HTML można odpuścić bo wprowadza więcej problemów niżeli jaki kolwiek pożytek), wszystko w zakładce "zaawansowane > wydajność"

3. czyścić i optymalizować baze co jakiś czas z zbednych porzuconych koszyków, starych statystyk itp (specjalny moduł dbclean albo: https://mypresta.eu/modules/administration-tools/database-optimization.html )

4. jeśli nie korzystasz z statystyk prestashop powyłączac wszystkie moduły dot. raportowania,analiz i statystyk (jest ich sporo). Google analitycs i tak jest najlepszym rozwiązaniem

5. Pousuwać z hooków(pozycji) moduły które nie są używane (jest ich sporo zazwyczaj)

6. http://codecanyon.net/item/prestashop-presta-speed/9199999 wykorzystać płatny moduł które robi wiekszośc rzeczy wypisanych powyżej + dodatkowo optymalizuje zdjęcia i czyści niepotrzebne pliki tymczasowe zdjęć + włacza kompresje gzip.

7. jeśli masz taką możliwość ustaw memory limit w phpie na 256mb albo nawet więcej

[athbus 106]

Hej wielkie dzięki za odpowiedź - spróbuję Twoich zaleceń. Punkt 7. już testowałem wczoraj i faktycznie dał sporego bosta. Zminiliśmy też trochę ustawienia mysqla.

Jeszcze raz dzięki spróbuję - mam nadzieję, że uda się złamać tą 1s.

[Bartosz Z 236]

Google analitycs i tak jest najlepszym rozwiązaniem

 

Google Analytics -> PIWIK

[Gość Rafiki]

piwika odpalasz na swoim serwerze = dodatkowe obciążenie

Google analitycs jest zdecydowanie lepszym narzedziem (większe możliwości) + nie obciąża dodatkowo naszego serwera + plus od googla dla Twojej strony

[blfr 225]

piwika odpalasz na swoim serwerze = dodatkowe obciążenie

Możesz uruchomić Piwika na oddzielnym serwerze.

 

Zatem pytanie czego Prestashop potrzebuje aby działać "jak żyleta", tj. zejść z czasem odpowiedzi serwera poniżej 0,8-1s?

Warto też być blisko swoich klientów, czyli mieć jak najmniejsze opóźnienie między serwerem i użytkownikami. Szczególnie, że używasz pewnie SSL-a i negocjacja połączenia wymaga kilku round-tripów.

 

Możesz wtedy też włączyć SPDY albo (nawet lepiej) HTTP/2.

[athbus 106]

Serwer stoi w PL, także akurat opóźnienia nie są problemem.

Ogólnie jednak widzę, że chyba jest jakiś problem ze skryptem. Na początku nie działał cach smarty, bo się okazało, że były błędnie nadane uprawnienia do folderów. To już chyba poprawiłem i skrypt trochę przyspieszył.

 

Z jakiegoś powodu nie działa cachowanie APC - niby jest uruchomione, ale nie ma żadnej różnicy między włączonym w preście APC a wyłączonym. Testowałem to na gołej instalacji presty z tą samą bazą produktową na innym serwerze i różnicą między włączonym a wyłączonym APC była kolosalna.

[Gość Rafiki]

1. serwer musi obsługiwać APC albo memcached (musi byc zainstalowane na serwerze).... w najnowszej wersji php (chyba od 5.6), apc nie jest obsługiwane z powodu opcache

2. korzystanie z memcached i apc w prescie osobiście uważam za niedopracowane.... zdarzało mi się kilka razy z włączonymi memcached aby skrypt przy kilkudziesięciu użytkownikach się "zapychał" i strona nie wczytywała się wcale (tak jakby zapchany był jakiś bufor... możliwe ze to wina złej konfiguracji memcached na serwerze)

 

Co do statystyk nie wiem dlaczego proponujecie piwika ... można je odpalić na zewnetrznym serwerze ale to nic nie zmienia - wiąże się to jedynie z dodatkowymi kosztami. Google analitycs jest a) za darmo b) szybsze w instalacji / wdrożeniu c) ma takie same a nawet wieksze możliwości d) strony w wyszukiwarce googla teoretycznie są lepiej traktowane z statystykami googla czy innymi elementami jak g+ itp. e) awaryjnośc hostingu jest bardziej prawdopodobna niż padnięcie serwerów googl'a f) nie trzeba aktualizowac skryptu (bez akualizacji na bierząco jesteśmy podatni na jakieś tam dziury)

Edytowano Październik 2, 2015 przez Rafiki (zobacz historię edycji)

[athbus 106]

APC jest uruchomione wg. phpinfo - co do konfiguracji to nie mam pojęcia, jak to wygląda bo to serwer zarządzany. Dowiem się czy mogą odpalić memcached na serwerze i porównam. Na razie przenoszę cały skrypt na ten tani serwer w ovh i zobaczę jak tam się zachowuje w porównaniu do gołej presty z taką samą zaimportowaną bazą produktową. Na tym tanim serwerze z gołą prestą + zaimportowaną bazą produktów udało mi się zejść do czasów poniżej 1s, a serwer kosztuje ~8zł i ma ułamek zasobów tego z iq.pl. Najlepsze, że w OVH ogólnie nic nie konfigurowałem - po prostu wrzucony LAMP + doinstalowany APC z paczki ubuntu.

 

Dodam, że w IQ mam dość starą wersję php - z tego co pamiętam to 5.3 ze względu na kilka skryptów, które nie obsługują późniejszych wersji php.

 

PIWIK też wg. mnie jest słabym rozwiązaniem poza tym rozliczam się z agencją po części jako % sprzedaży, więc raczej nei byliby szczęśliwy, gdybyśmy mieli się rozliczać na podstawie skryptu, do którego mam pełny dostęp na serwerze ;-)

[nesti 67]

Jeśli chodzi o shared to mydevil.net, mam preste u nich i na moim łączu ładuje się w ułamku sekundy