http://forum.php.pl/viewtopic.php?t=11888#76431 - załamałem się - po tym teście - Zciągnąłem osCommerce ze strony zainstalowałem wizardem i zrobiłem ten test. 158 zapytań do bazy danych przy wyświetleniu jednej strony to chyba trochę dużo. Stąd moje pytanie - jak bardzo staracie się optymalizować ilość zapytań do bazy przy otwarciu pojedynczej strony, jakie ilości uznajecie za dopuszczalne ?

Na stronach tworzonych przezemnie na wstepie jest zawsze jedno zapytanie a co pozniej jest potrzebne to juz, ze tak powiem "prywatna sprawa strony". Ale ilosci 150 8O zapytan w zyciu nie potrafilbym chyba osiagnac, chyba ze przy niewlasciwym skonstruowaniu zapytania w petli pobieral bym jakies dane ale to raczej sa wyjatki na ktore mozna sobie pozwolic w panelu admina a nie w standardowo dostepnej stronie.

A to ciekawe. I w sumie - chyba mnie cieszy. Co prawda interesowałby mnie sposób, w jaki przeprowadziłęś ten test (bo nie pamiętam, czy os posiada taką funkcję debagującą) ale zazwyczaj bardzo stresowała mnie ilość zapytań do bazy. Dlatego staram się ją ograniczać do minimum, i nawet przy dużysh skryptach zazwyczaj nie przekraczam 10 - 15 zapytań.
Czasem jednak powoduje to znaczną komplikację kodu.
A, jeśli jest tak jak mówisz - widać, że znacznie ważniejsza jest optymalizacja kodu, niż ilości zapytań, ponieważ osCommerce jest systemem, któy chodiz naprawdę dobrze, szybko i, w chwili obecnej - stablinie. Jeśli więc sprawnie chodzi system z taką ilością zapytań.... może warto pozbyć się kompleksów?

Aktywowałem logowanie wszystkich zapytań przychodzących do bazy w pliku i policzyłem ile było przy jednym otwarciu strony. Piszesz że OSC chodzi szybko - ale pytanie, czy ktoś testował go na sporym obciążeniu - np. 500 klientów jednocześnie - to daje 500*180=90000 - tego MySQL raczej nie przetrzyma.

Może warto by było przyjrzeć się tym zapytaniom?
Bo jeżeli to są podstawowe selecty bez joinowania itp. to taka ilośc jeszcze (ale nie do końca moim zdaniem) jest akceptowalna..
phpBB by Przemo na mojej stronie przy wyświetleniu portalu pokazuje:

Hej,
wytrzyma i jestem o tym przekonany...
w działaniu widziałem ostatnio gorsze sytuacje,
generalnie wydaje mi sie (poparte wykładem) iż moc jaka drzemie w mysql jest przez zwykłych śmiertelników nie doceniana i mało kto tworzący sobie cms "dla qmpla" wykorzystuje nawet 20% jego mocy, a tak naprawde mysql stojący na dedykowanej maszynie nie ma z tym problemów, schody się pojawiają kiedy potrzebne są zaawansowane zapytania :wink:

Pozdrawiam patS.

P.S. temat raczej nie na Pro chyba :wink:

No na dedykowanej maszynie to widomo, ze parametry pracy wzrastają.
A temat pracy myślę, że jak najbardzioej na Pro. W końcu nie piszemy tu skryptów, tylkozastanawiamy się nad wydajnością i optymalizacją - czyli inżynieria programowania

Sprawdziłem statystycznie:
- 3 to "UPDATE"
- 4 to "LEFT JOIN"
- 14 wyciągają wszystkie wiersze z tabeli - brak "WHERE"
- 77 zawiera COUNT(*)
- 111 (około) to wygenerowanie drzwka kategorii produktów - pytania typu:
[sql:1:896ca5a46a]select count(*) as total from products p, products_to_categories p2c where p.products_id = p2c.products_id and p.products_status = '1' and p2c.categories_id = '14'
select categories_id from categories where parent_id = '11'[/sql:1:896ca5a46a]

Sklep ktory ma w jednym momencie 500 klientow moze sobie pozwolic na wlasne, dedykowane oprogramowanie

Pytan jest tak wiele zapewne dlatego z osC ma byc elastyczny. Poza tym chyba jeszcze nikt nie podal sensownego sposobu prezentacji struktur drzewiastych.

Ale można np cache'ować wyniki zapytań... to powinno zmniejszyć diametralnie ilość zapytań do bazy...

Sam mysql ma od wersji 4.0.ilestam cache zapytan i robi to calkiem dobrze. Oczywiscie dodatkowo mozna cacheowac ale w wiekszosci wystarcza to co on daje.

http://www.depesz.pl/various-sqltrees.php - warto poczytać jeśli chodzi o prezentację drzew w bazie

------------



Wydaje mi się że zdecytowanie warto cache-ować wszelkie drzewa prezentowane w bazie - to są najgorsze zapytanie (zwłaszcza rekurencyjne)

Ja myślałem o cache'owaniu gotowych struktur - np php, co byłoby szybsze i jednocześnie efektywniejsze. Samo cache'owanie wyników zapytań byłoby duuużo mniej efektywne. Zwłaszcza przy dużej liczbie zapytań.