Preporučeni br. MySQL upita po jednoj stanici?

[Vlasterx]

Da li postoji neki preporučeni broj MySQL upita po jednoj stranici sajta? Do koliko upita mogu da idem, a da sajt ne počne da preopterećuje server?
Da li postoji neki preporučeni broj upita za sajtove sa malom, srednjom i velikom posećenošću ili to na kraju priče zavisi samo do mašine na kojoj se sajt hostuje?

Ovo me zanima zbog optimizacije koda i brzog odziva sajta jer pokušavam da napravim neki svoj CMS koji ne bih na kraju da preopteretim i napravim nešto sporo i prezahtevno za hostovanje.

 

[Mare]

mislim da je upit jako relativna stvar obzirom da postoje upiti koji rade od 0,01 sec do nekoliko stotina sati...

 

[GoranKostic]

Tačno tako, nije sve do broja upita, već do strukture baze, tipa tabela (MyISQM, InnoDB), upotrebe indexa, transakcija...

 

[Vlasterx]

hm, loše sam se izrazio, ali sam u međuvremenu shvatio rešenje za problem. Hvala u svakom slučaju.

 

[Mare]

u svakom slucaju upite treba optimizovati, uzimati samo ono sto je neophodno iz baze...

 

[Skot]

I sto manje JOIN upita. Trenutno imamo oko 3000 upita po sekundi na projektu na kom radimo. Imamo strasnih problema iako imamo 8 SQL servera (quad masine sa raid diskovima i gomilom GB RAM-a) i to najvise sa JOIN SQL upitima i neindexiranim tabelama. Dakle za vecu posecenost site-a sto jednostavniji query-ji. Posle toga sto manje query-ja ako je ikako moguce podesiti. Kod koji smo nasledili ima i po 100 queryja na nekim stranicama - smrt kako to lose radi. Izbegavaj COUNT() queryje posebno ako radis na tabelama koje imaju milion + redova - pravi totals tabele u kojima smestas zbirne vrednosti. Eto toliko sto se tice nekog osnovnog vezanog za upite po stranici. Razmisli - ako vec razvijas svoj CMS - da ubacis i podrsku za neku vrsu cache-iranja. Da li memcache, ili nesto sto ce da pise stranice na hard disk, ali to je nesto sto svi veliki sajtovi koriste.

 

[Nick]

Da se nadovežem na Skota:
Nemoj da si lenj kada kreiraš upite - ne koristi Select *, ako to nije upravo ono što ti treba; ako ćeš raditi pretraživanje po nekom polju (i/ili sortiranje) - indeksiraj ga; normalizuj bazu, ali ne po svaku cenu - to može da ubija performanse...
Pošto je CMS u pitanju, obrati pažnju da često postoje statične stranice, kao i delovi sadržaja koji se kreiraju dinamički, ali se ne osvežavaju često. Umesto u bazu snimaj te strane kao običan .html fajl (ekstenzija nije bitna, samo ga učitaš) i kad zatreba učitaće se odmah i neće smarati bazu. Naravno, svaki put kad se iz admin aplikacije izmeni neka strana ili neki podatak koji menja sadržaj modula, to se ponovo snima kao .html fajl.
To su neka moja razmišljanja i neke prakse koje sam koristio kod nekih jednostavnijih CMS-ova koje sam pravio u PHP, kao i u ASP.NET.

 

[Skot]

Eh da - bas ovo sto Nick kaze - normalizuj ali ne po svaku cenu. Select samo polja koja ti trebaju ako moze. Stavljaj LIMIT na kraju ako znas koliko redova ces uzeti (query sa LIMIT 1 se izvrsava brze od queryja bez LIMIT-a).

 

[Vlasterx]

Hvala na korisnim savetima Hoću da ovo napravim kako treba, pa ovakvi praktični saveti dosta znače.