Wolno działający sklep

[studioa4]

Witam

Sklep : https://grafikareligijna.com/
Wersja presty : 1.7.6.4
Wersja PHP - 7.2

Poszukuję sposobów na przyśpieszenia działania sklepu, głównie chodzi o strony z produktami, zaplecze oczywiście też byłoby lepsze gdyby produkty dodawały się szybciej ale jakoś to zniesiemy, od jakiegoś czasu sklep chodzi o wiele gorzej i myślę że z tego powodu pojawia się codziennie wiele porzuconych koszyków. Przez dwa tygodnie przeglądnąłem wiele stron w internecie i jeszcze więcej sposobów w nich wyczytanych wdrażałem i jak ładowanie strony głównej trochę się poprawiło to zmiany między kombinacjami w produktach czasami dobijają.. Po tylu próbach samodzielnego działania stwierdziłem że jednak lepiej zapytać kogoś kto się zna na rzeczy  

Produktów które na razie wrzucone są do sklepu jest 967 wiele z nich ma dużo (w zasadzie nie wiem ile to dużo dla presty) atrybutów bo np 70 i wiele z nich ma osobne zdjęcia ładowane podczas wybrania kombinacji - łącznie presta przesyła do google merchant ponad 35 tyś produktów, docelowo produktów może być 2 razy tyle, stale uzupełniamy

Serwery mamy na nazwie, zwykły współdzielony cloud docelowo mają na nim stanąć 2-3 presty i nie będzie tam niczego więcej - przed zakupem serwerów powiedziano nam w nazwie że na tak mała ilość spokojnie taki serwer wystarczy

Rzeczy które pamiętam które wdrażałem żeby przyśpieszyć działanie presty :

- bazy danych znajdują się na drugim serwerze (wersja php 5.6 ze względu na stary sklep który na innym nie działa) - jedna z części partycjonowania serwera, drugim etapem miało być zakupienie S3 od Amazona w celu przechowywania tam zdjęć ale perspektywa aktualizowania ręczenie codziennie serwera trochę przeraża szczególnie że presta dzieli te zdjęcia na folderki, ciężko pewnie byłoby się połapać które są nowe
- włączony zewnętrzny serwer Memcached na nazwie
- wyłączenie większości modułów statystyk, kopalni danych itd wszystko co według mnie nie jest potrzebne do działania
- z opcjami wydajności w panelu administracyjnych kombinowałem w każdą możliwą stronę czyszcząc każdorazowo ręcznie pamięć cache
- max input vars zwiększone w htaccess :   php_value max_input_vars 25000
- tak samo jak w przypadku wydajności próbowałem z pamięcią podręczną Smarty 
- jestem w trakcie zamieniania wszystkich zdjęć produktów na zdjęcia o mniejszej rozdzielczości (formaty jpeg2000 i jpgeg xr podobno nie są obsługiwane przez większość przeglądarek więc chyba odpadają), chcieliśmy kupić moduł żeby wdrożyć format WEBP - niestety do jego działania potrzebne są dodatkowe rozszerzenia na serwerze a otrzymałem od nazwy informację że można to robić tylko na dedyku 
- rozważaliśmy zlecenie optymalizacji sklepu firmie zewnętrznej ale audyt, przebudowa strony itd zabiera i dużo czasu i kasy a teraz takie czasy że z tym ciężko

Przeczytałem o magicznym wręcz module Page Cache Ultimate który rzekomo potrafi skrócić ładowanie z 5 sek do 1/3 sekundy, wie ktoś czy działa i warto? jeżeli tak to kolejnym problem będzie pewnie jego instalacja bo z tego co czytałem trzeba wydzielić fragmenty strony na które nie będzie działał a to raczej nie mój poziom

Dodatkowo czasami strona działa o wiele szybciej i na teście potrafi wyjść że załadowała się w 4 sek a czasami 18 sek

Robiłem również kroki które zalecały testery prędkości strony : gtmetrix i PageSpeed Insights, tylko te w których po poszukaniu w necie jako tako ogarniałem o co chodzi, załączam screeny  zakładki wydajność i wyników testów - teoretycznie coś się poprawiło przez to moje grzebanie bo wcześniej wynik A w rankingu GT wynosił 76 teraz 98%

Jakby ktoś miał jakieś pomysły to proszę o info  i sory za tak dużo treści  

 

Edited October 27, 2020 by studioa4 (see edit history)

[adiem]

Cześć,

Niestety niezbyt dobrze to wygląda, sklep rzeczywiście ładuje się długo, blisko 30 sekund to słaby wynik, wiele osób zrezygnuje z zakupu zanim ujrzy w pełni stronę główną. Ewidentnie te serwery są obecnie przeciążone, skoro miałeś czas 16.6 sekundy (pewnie w godzinach porannych).

https://gtmetrix.com/reports/grafikareligijna.com/SdgxVetD

Na początek proponuję skorzystać z porządnego hostingu, nigdy nie miałem zaufania do nazwy, te współdzielone działają bardzo wolno.

Polecałem na tym forum Kylos.pl na którym obecnie działa nasz jeden sklep. Bezawaryjna praca od ponad 2 lat, w przypadku, kiedy spóźnimy się z opłaceniem proformy dzwonią i przypominają o zaległościach. Został także poprawiony błąd z niepoprawnym wyświetlaniem miejsca na dysku, wcześniej trzeba było z konsoli wydawać polecenie resize2fs /dev/vda1.

Jeszcze lepszym wyjściem jest serwer VPS (lub dedyk w przyszłości jak się biznes rozwinie) na hetzner.de, od ponad roku działa tam nasz główny sklep - notabene na tym samym szablonie co grafikareligijna.com. 🙂 Automatyczna płatność za usługę z karty, możliwość tworzenia snapshotów (migawek) z kopią bezpieczeństwa całego systemu, super wsparcie o każdej porze dnia i nocy. Całość stoi na Debianie 10.6, serwer www to nginx 1.19.3 + pagespeedmod, baza - maria DB 10.3.23, php w wersji 7.3. Sklep działa na thirtybees 1.1.0 (fork presty 1.6, rewelacyjna sprawa, wiele błędów poprawionych, nie muli po wejściu w moduły tak jak powinno być). Serwer VPS konfiguruje się raz, a następnie okresowo aktualizuje. Gdybyś był zainteresowany to daj znać.

Moim zdaniem w pierwszej kolejności powinieneś zmienić hosting, a docelowo przejść na TB - nigdy nie osiągniesz takiej szybkości działania BO na PS 1.7. Migracja z php 5.3 na wersję 7.x da również zauważalny przyrost ładowania sklepu. Skompresuj też zdjęcia na głównej w sliderze, przykładowy obrazek zamiast 3328,9 KiB może zajmować 1843,5 KiB. Apache tez nie jest demonem prędkości, zdecydowanie lepszym wyborem jest nginx lub lighttpd.

Docelowo pomyśl nad podpięciem Cloudflare, trzymaj zdjęcia na zewnętrznym, szybkim serwerze CDN, używamy Keycdn.com i jego mogę polecić.

Edited October 27, 2020 by adiem (see edit history)

[endriu107]

Generalnie jaki jest sens ładować aż 3 różne moduły menu? Poza tym kiedyś znajoma osoba robiła ankietę do pracy magisterskiej i jednym z pytań było ile slidów po odwiedzeniu strony przeglądasz wyniki były 1 - 70%, 2 - 28% więcej niż 2 - 2%, więc szkoda obciążać stronę niechcianymi grafikami. Poza tym w profilerze sprawdziłbym co tak na prawdę opóźnia stronę również na stronach produktów. Kolejna sprawa dotyczy atrybutów produktów, jeśli jest ich dużo to one również negatywnie wpływają na ładowanie się strony, tutaj może pomóc moduł np. AWP.

 

Dodam jeszcze że memcached warto sprawdzić czy tak na prawdę daje pozytywne wyniki, spotkałem się kilka razy z sytuacją w której efekt był odwrotny.

[studioa4]

13 hours ago, adiem said:

Cześć,

Niestety niezbyt dobrze to wygląda, sklep rzeczywiście ładuje się długo, blisko 30 sekund to słaby wynik, wiele osób zrezygnuje z zakupu zanim ujrzy w pełni stronę główną. Ewidentnie te serwery są obecnie przeciążone, skoro miałeś czas 16.6 sekundy (pewnie w godzinach porannych).

https://gtmetrix.com/reports/grafikareligijna.com/SdgxVetD

Na początek proponuję skorzystać z porządnego hostingu, nigdy nie miałem zaufania do nazwy, te współdzielone działają bardzo wolno.

Polecałem na tym forum Kylos.pl na którym obecnie działa nasz jeden sklep. Bezawaryjna praca od ponad 2 lat, w przypadku, kiedy spóźnimy się z opłaceniem proformy dzwonią i przypominają o zaległościach. Został także poprawiony błąd z niepoprawnym wyświetlaniem miejsca na dysku, wcześniej trzeba było z konsoli wydawać polecenie resize2fs /dev/vda1.

Jeszcze lepszym wyjściem jest serwer VPS (lub dedyk w przyszłości jak się biznes rozwinie) na hetzner.de, od ponad roku działa tam nasz główny sklep - notabene na tym samym szablonie co grafikareligijna.com. 🙂 Automatyczna płatność za usługę z karty, możliwość tworzenia snapshotów (migawek) z kopią bezpieczeństwa całego systemu, super wsparcie o każdej porze dnia i nocy. Całość stoi na Debianie 10.6, serwer www to nginx 1.19.3 + pagespeedmod, baza - maria DB 10.3.23, php w wersji 7.3. Sklep działa na thirtybees 1.1.0 (fork presty 1.6, rewelacyjna sprawa, wiele błędów poprawionych, nie muli po wejściu w moduły tak jak powinno być). Serwer VPS konfiguruje się raz, a następnie okresowo aktualizuje. Gdybyś był zainteresowany to daj znać.

Moim zdaniem w pierwszej kolejności powinieneś zmienić hosting, a docelowo przejść na TB - nigdy nie osiągniesz takiej szybkości działania BO na PS 1.7. Migracja z php 5.3 na wersję 7.x da również zauważalny przyrost ładowania sklepu. Skompresuj też zdjęcia na głównej w sliderze, przykładowy obrazek zamiast 3328,9 KiB może zajmować 1843,5 KiB. Apache tez nie jest demonem prędkości, zdecydowanie lepszym wyborem jest nginx lub lighttpd.

Docelowo pomyśl nad podpięciem Cloudflare, trzymaj zdjęcia na zewnętrznym, szybkim serwerze CDN, używamy Keycdn.com i jego mogę polecić.

Wielkie dzięki za odpowiedź, serwery w nazwie mamy od wielu wielu lat, za czasów jak były tam normalne strony, wordpress i sklepy w starym stylu typu Quick Cart to wszystko śmigało dobrze, dlatego też miałem nadzieje że z prestą też sobie poradzą..

A czy o tym hostingu coś wiesz? https://cyberfolks.pl/hosting-prestashop/  wolałbym na razie współdzielone bo przyznam szczerze że konfiguracja serwerów, samodzielna ich obsługa to ciemna magia, nigdy nie używałem i nie próbowałem więc ogarnięcie trochę zejdzie a sklepy muszę uruchomić jak najszybciej..

Co do php - na serwerze na którym jest sklep jest php 7.2 jedynie na tym co jest baza jest 5.3 - też w sumie nie wiem czy php wyższe powinno być tam gdzie baza czy tam gdzie sklep

[studioa4]

12 hours ago, endriu107 said:

Generalnie jaki jest sens ładować aż 3 różne moduły menu? Poza tym kiedyś znajoma osoba robiła ankietę do pracy magisterskiej i jednym z pytań było ile slidów po odwiedzeniu strony przeglądasz wyniki były 1 - 70%, 2 - 28% więcej niż 2 - 2%, więc szkoda obciążać stronę niechcianymi grafikami. Poza tym w profilerze sprawdziłbym co tak na prawdę opóźnia stronę również na stronach produktów. Kolejna sprawa dotyczy atrybutów produktów, jeśli jest ich dużo to one również negatywnie wpływają na ładowanie się strony, tutaj może pomóc moduł np. AWP.

 

Dodam jeszcze że memcached warto sprawdzić czy tak na prawdę daje pozytywne wyniki, spotkałem się kilka razy z sytuacją w której efekt był odwrotny.

Zajmę się tymi grafikami, dzięki  W trybie deweloperkim? nie pomyślałem żeby sprawdzić.. co do modułu AWP to już się nim interesowałem ale pisze że jest on potrzebny kiedy ilość 1000 atrybutów nie wystarcza, u nas będzie do 100 w sumie

W takim razie zrobię testy na wyłączonym i włączonym i porównam  

[rrataj]

Zaczął bym od profilowania i sprawdzenia które zapytania do bazy trwają najdłużej. W tym przypadku podejrzewam że sklep działa wolno poprzez dużą ilość kombinacji - niestety presta 1.7 tego nie lubi.

Daj znać jakie wyniki masz jeżeli ustawisz _PS_DEBUG_PROFILING_ na true (plik "config/defines.inc.php"). Wtedy po przeładowaniu strony wyniki pojawią się pod footerem.

[studioa4]

6 minutes ago, rrataj said:

Zaczął bym od profilowania i sprawdzenia które zapytania do bazy trwają najdłużej. W tym przypadku podejrzewam że sklep działa wolno poprzez dużą ilość kombinacji - niestety presta 1.7 tego nie lubi.

Daj znać jakie wyniki masz jeżeli ustawisz _PS_DEBUG_PROFILING_ na true (plik "config/defines.inc.php"). Wtedy po przeładowaniu strony wyniki pojawią się pod footerem.

Takiego czegoś to nie znałem, załączam ss samej góry tego co wyskoczyło

[rrataj]

2 minutes ago, studioa4 said:

Takiego czegoś to nie znałem, załączam ss samej góry tego co wyskoczyło

To jest na pewno strona z F.O. która wolno się ładuje?

Te wyniki są bardzo dobre.

[studioa4]

Właśnie to jest bardzo dziwne, raz ładuje się bardzo szybko a raz jest trafedia, wrzuciłem ss strony typowo z produktem gdzie są kombinacje, teraz wrzucam strony głównej - dwa screeny zrobione jeden po drugim po odświeżeniu strony

[rrataj]

Nie jest to dziwne jeżeli używasz cache  

Poniżej tych statystyk masz jeszcze listę zapytań do DB, wraz z czasem ich wykonywania po prawej, poproszę ss kilku pierwszych, oczywiście dla przypadku w którym występuje problem (czyli dla tego, gdzie strona ładuje się długo).

[studioa4]

No i się wyjaśniło  

dla strony głównej : 

[studioa4]

i dla produktu 

[rrataj]

W zasadzie to nie do końca się wyjaśniło.. Jedyne co z tego mogę wywnioskować to że zapytania SQL nie są tutaj problemem

Wygląda na to że któraś metoda initContent() robi coś czego nie powinna. Czy masz jakieś klasy lub controllery w /overrides/ ?

[studioa4]

[rrataj]

A mógłbyś pokazać jeszcze zawartość "/override/classes/controller/",  "/override/controllers/front/"  oraz "/override/controllers/front/listing". 

[studioa4]

/override/classes/controller/

[studioa4]

/override/controllers/front/

[studioa4]

/override/controllers/front/listing - tego foldera nie ma

 

[rrataj]

@studioa4 Chodziło mi o listę plików w tych katalogach Czyli "/override/controllers/front/*" oraz "/override/classes/controller/*"

[studioa4]

tak rozumiem, ale jest tylko po 1 pliku index w każdym z tych katalogów dlatego wkleiłem ich kod

[rrataj]

Ok, więc to także nie jest problem z `overrides` i jakimś customowym kodem.

Jedyne co mi jeszcze przychodzi do głowy to że jakiś moduł tutaj powoduje problem, ale z racji że profilowanie hooków nie działa w preście, to ciężko jest powiedzieć który.

Dalsza analiza wydajności powinna być przeprowadzona mając dostęp do środowiska i praktycznie sprawdzając krok po kroku gdzie następuje to spowolnienie. 

[studioa4]

Napisałem priv, wielkie dzięki