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

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

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

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.

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

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

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.

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

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.

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