Ilośc zapytań do bazy w skrypcie sklepu internetowego...

[pietrovek 19]

Hej,

 

Właśnie wykonuję kodowanie grafiki + skrypt dedykowany do sklepu internetowego, cóż dużo mówić - przy obecnej bazie (której schematu autorem nie jestem) średnio wyszło mi 15 zapytań/stronę to i tak znacząca poprawa gdy z obecny skrypt (robiony przez niby profesjonalną firmę) wykonuje ich ok. 80-100/stronę (po optymalizacji, wcześniej - gdzieś to opisywałem już na forum - było znacznie więcej).

 

Moje pytanie brzmi - czy 15 zapytań na stronę to dużo czy ok? Bowiem istniałaby możliwość zejścia do ok. 10 zapytań/stronę jednak kosztem dużo mocniej skomplikowanych algorytmów w php.

 

2 z tych 15 zapytań podczas wykonywania generują tabelę tymczasową przechowywaną w pamięci.

 

No i ty pytanie do innych - ile średnio zapytań wykonują Wasze skrypty? Czy warto komplikować php dla 5 zapytań? (procentowo 5 zapytań to 33% ale kodu php będzie pewnie z 50% więcej) Tymbardziej, iż czas generacji strony w tej chwili to ok. 0,01s.

 

Pozdrawiam,

Piotr

Edytowano Maj 31, 2012 przez Gość (zobacz historię edycji)

[ednet 136]

w sklepie internetowym 15 zapytań sql w 0,01 sekundy to bardzo mało.

 

NIe mozna przesadzać, lepiej zrobić trochę więcej szybkich zapytań niż mniej zapytan z dużą ilością JOINów. Przy rozbudowanych JOINAch i duzej liczbie rekordów mysql potrafi zwolnić.

 

Ważny jest czas generowania strony w PHP a nie ilosć zapytań.

Opencart ma kolo 100 zapytan w czasie generowania 1 podstrony i uważany jest a szybki system

Edytowano Maj 31, 2012 przez ednet (zobacz historię edycji)

[pietrovek 19]

ok, dzięki - bardzo mi pomogłeś, czas o którym napisałem (0.01s) to czas generacji strony w php (od startu skryptu do "wyplucia go"), fakt faktem że chyba zmienię odrobinę skrypt wtedy średnio będzie 20 zapytań ale znacznie uprości to budowę 2-ch głównych zapytań pobierających produkty do wyświetlenia...

 

cóż..pozostaje tylko zoptymalizować CSS który zajmuje ~10KB...bo szablon w sumie nie ma niczego co nie jest "stylizowane"

[maniack 403]

.

Edytowano Wrzesień 13, 2017 przez maniack (zobacz historię edycji)

[pietrovek 19]

wszystko co mówisz prócz cache w htaccess jest włączone - plików CSS jest 2 (font+css) lub razem 3 dla nieszczęsnego IE serwer przesyła wszystko skompresowane więc po kompresji zajmuje to 2kB.

 

ciekawe swoją drogą że we wszystkich poradnikach "straszą" że css który zajmuje > 8kB to "zło"

 

Sprite'y oczywiście są w użyciu

 

dzięki za cenne wskazówki

Edytowano Maj 31, 2012 przez pietrovek (zobacz historię edycji)

[elcct 159]

Umiejętnie stosując caching możesz zejść do 1-3 zapytań na stronę w większości wypadków

[pietrovek 19]

Umiejętnie stosując caching

 

mógłbyś rozszerzyć, proszę?

[regdos 1848]

Wiele zapytań zapewne jest o rzeczy, które się nie zmieniają lub zmieniają rzadko, można je cachować do plików żeby nie robić zapytań SQL a jeżeli te dane się zmienaią to odświeżyć cache.

[pietrovek 19]

no tak, np. menu główne (nie kategorii) tylko caching trzeba by w php napisać i kiedy sprawdzać czy się coś zmieniło? co jakiś czas? co ileś odwołań do skryptu?

 

jedyne co mi przychodzi do głowy to np. co 100 "requestów" - wysyłam zapytanie do bazy i cachuje wynik oraz np. wymuszana aktualizacja raz na 2h...

 

tylko tak myślę jak cachować wyniki...w formie plików? zatem załadowanie pliku i przetworzenie go np. używając implode nie będzie się dłużej wykonywać niż zapytanie do mysql? przecież sam serwer mysql też cachuje wyniki zapytań...więc czy wydajność na pewno wzrośnie?

 

dobrze rozumuję?

Edytowano Maj 31, 2012 przez pietrovek (zobacz historię edycji)

[elcct 159]

1. Wiele jest podejść. Całkiem skuteczne jest np.

 

Podziel sobie stronę na strefy / sekcje, do których wyświetlenia musisz pytać się bazy:

 

- takie które nie zmieniają się wcale, lub bardzo rzadko i ich aktualność nie jest istotna z punktu widzenia użytkownika np. podobne produkty,

kupili również itd. wyniki takich zapytań można wrzucić do cache z terminem ważności np. 8-24h

 

- elementy, które zmieniają się po wykonaniu jakiejś akcji np. dodanie do koszyka, dodanie komentarza. Wynik takich zapytań dajesz do cache z maksymalnym terminem ważności,

ale kasujesz z cache, gdy użytkownik wykona jakąś akcje np. owe dodanie do koszyka.

 

- elementy, które zmieniają się często, ale ich aktualność co do minuty nie jest istotna np. ostatnio kupione produkty. Wynik takiego zapytania możesz wrzucić do cache

z np. 5-15 minutowym czasem ważności.

 

Lepiej cachować wynikowy html, niż zapytania - wtedy odpada też praca dla php na przetwarzanie tego.

 

 

2. Do tego najlepiej użyć memcached lub podobnego key-value store.

 

To taka baza danych, która dla danej zmiennej (klucza) zwraca jego zawartość np. wynik zapytania, kod html, cokolwiek

 

Struktura czegos takiego dla drugiego przypadku moze wyglądac mniej więcej tak (pseudokod):

 

funkcja podaj_koszyk(id_koszyka)
{
klucz = 'koszyk' + id_koszyka

koszyk = memcached->get(klucz)

if(koszyk) return koszyk

koszyk_dane = zapytanie_do_bazy(id_koszyka)
koszyk = zrob_html(koszyk_dane)
memcached->set(klucz, koszyk)

return koszyk
}

funkcja dodaj_do_koszyka(id_koszyka, id_produktu)
{
zapytanie_do_bazy_dodajace_do_koszyka(id_koszyka, id_produktu)

klucz = 'koszyk' + id_koszyka
//kasujemy koszyk z cache, aby sie odswiezyl
memcached->delete(klucz)
}

Tak mysql cachuje wyniki zapytań, ale i tak musisz się z nim połączyć, zapytanie musi zostać przetworzone, aby sprawdzić czy znajduje sie w cache - także, jeśli

cokolwiek się zmieni w tabeli, wynik zapytania jest kasowany.

Np. jak pobierasz sobie dane jakiegoś użytkownika, jeśli dane innego użytkownika się zmienią, cache dla zapytań o jakiekolwiek użytkownika jest kasowane.

 

Uzywając osobnego cache, masz kontrolę nad tym.

Edytowano Maj 31, 2012 przez elcct (zobacz historię edycji)

[regdos 1848]

http://pear.php.net/package/Cache_Lite

 

I możesz tym bez problemu po stronie admina czyścić daną część cache gdy coś się zmieni np. drzewo kategorii - dodajesz, usuwasz, zmieniasz kolejność i z poziomu panelu przy okazji takiej zmiany czyścisz tą część cache gdzie trzyma to drzewo.

[pietrovek 19]

ok, przemyślę sposób...oczywiście sklep podzielony jest na bloki - każdy z nich wykonuje się oddzielnie, później łączone są w jedność i wyświetlane.

 

oki, dziękuje za objaśnienie.