Ogromna ilość zapytań do bazy Opcje

[Piotreeek]

Witam

Posiadamy sklep internetowy oparty o cs-cart. Od pewnego czasu serwer zaczął zamulać. Został zmieniony na mocniejszy, ale nic to nie dało. W środku nocy, kompletnie bez ruchu wygląda to tak: Uptime: 708 Threads: 3 Questions: 216418 Slow queries: 0 Opens: 283 Flush tables: 2 Open tables: 309 Queries per second avg: 305.675. W dzień zapytań jest jeszcze dużo więcej.

Pytanie jest takie: jak lub za pomocą czego zdiagnozować problem? Od czego najlepiej zacząć poszukiwania?

Ewentualnie prośba o polecenie dobrego fachowca.

Z góry dziękuję i pozdrawiam
Piotrek

[viking]

No cóż. Demo sklepu pokazuje 114 zapytań na głównej, 498 na stronie produktu. Kupuje się g... to ma się g.

[Piotreeek]

No ok, ale takie stwierdzenie nie rozwiązuje naszego problemu.

[viking]

No a co tu rozwiązywać? Skoro demo sklepu generuje 500 zapytań na odsłonę jednego produktu + kolejne 50 cachowanych, to 100 osób online daje abstrakcyjną liczbę żeby głupi produkt obejrzeć. Jedyne wyjście to kupować silniejszy sprzęt do serwowania tego śmietnika.

[nospor]

Demo sklepu pokazuje 114 zapytań na głównej, 498 na stronie produktu.

Wow, nie ogarniam na jakiej fazie trzeba byc by takie cos napisac :/
@viking masz moze jakies przykladowe zapytania? Ot tak, z ciekawosci

[Piotreeek]

Serwer jest mocny: Intel® Xeon® CPU D-1531 @ 2.20GHz 12 rdzeni i 128 gb ramu, więc zmienianie na mocniejszy nic nie da.

[Pilsener]

Wow, nie ogarniam na jakiej fazie trzeba byc by takie cos napisac :/

Nie trzeba fazy. Wystarczy użyć ORMa, dać do frontendu parę obiektów typu User czy Product a potem w templacie:

[HTML] pobierz, plaintext 
<for product in user.products >
   {product.categories.first.createdBy.name.id}
   <for detail in product.details>
       {detail.feature.local.name}
   </for>
</for>
[HTML] pobierz, plaintext 

- wyświetlać co się chce, korzystając ze wspaniałości narzędzi.

Do tego wystarczy ustawić np. fetchMode=EAGER (tak na wszelki wypadek) i nagle pobierając np. kategorię bloga stwierdzamy, że feczujemy pół bazy

Mój rekord to ponad 5 tys. zapytań na formularz edycji użytkownika. Po optymalizacji ta liczba spadła do 10, jednak wymagało to prawie całego dnia pracy i zrezygnowania z automatyki na rzecz ręcznego napisania query buildera.

Moja rada: przed wyborem rozwiązania analizować kwestie wydajności, zrobić odpowiednie testy, zapewnić moce przerobowe i tak dalej.

[viking]

Wow, nie ogarniam na jakiej fazie trzeba byc by takie cos napisac :/
@viking masz moze jakies przykladowe zapytania? Ot tak, z ciekawosci

Wejdź na demo i dopisz ?debug=true. Nie wiem czy nie trzeba przez admina przejść wcześniej.

[ohm]

Serwer jest mocny: Intel® Xeon® CPU D-1531 @ 2.20GHz 12 rdzeni i 128 gb ramu, więc zmienianie na mocniejszy nic nie da.

Na tyle ramu ile przydzielone jest dla mysqla? (czy tam jakiej bazy używasz) bo bez ingerencji w zapytania możesz spróbować przepchnąć wszystko do cache mysqla (zwiększyć mu ten cache do dużo większych rozmiarów), jest to rozwiązanie doraźne, ale może odrobinę pomoże.

[Piotreeek]

Proszę:

max_allowed_packet = 512M
key_buffer_size=4600M
thread_concurrency = 16
wait_timeout=10
thread_handling=pool-of-threads
table_open_cache=4000
query_cache_size = 1000000