On Monday 20 February 2006 16:22, Octavian Rasnita wrote: > Cel mai mare tabel are daca nu ma insel sub 600.000 > inregistrari si baza de date are putin peste 100 de tabele, > asa ca nu e un monstru imens, insa totusi functioneaza > relativ lent. Nu am acces la codul sursa al programelor ca > sa vad daca nu se poate imbunatati ceva, dar sunt facute in > PHP.
Depinde mult de query-urile facute dar ca idee la 500 queries/secunda, mysql, dual p3-800 pe o tabela de 150k linii nici nu se simtea. Deci eu zic sa faci lobby foarte puternic pt a se face un audit/profiling/optimizare la nivelul aplicatiei. In experienta mea optimizarile la nivel de aplicatie au imbunatatit performanta de cateva ori... > Principala nevoie e legata de viteza la selectare/afisare > si apoi la introducerea/modificarea datelor, insa nu pentru > baze de date mici, ci pentru unele mai mari, caci acea baza > de date va creste in timp. Vezi ca si tabele se fac cu cap. Adica se tine in o tabela accesate des doar campurile strict necesare accesului des si se separa bloat-ul (campuri asociate acelora interogate des dar care sunt accesate mult mai rar). Astfel obtii tabele care poate au numar mai mare de linii dar au nr de coloane foarte mic si ajuta la cachingul in RAM si la performanta in general. Alta solutii sunt evident indecsii care trebuie sa urmareasca exact query-urile efectuate. Porneste MySQL cu un parametru de logare a slow query-urilor (am uitat care era) si te uiti periodic in el si vezi ce query-uri se fac tarziu si cu comanda "EXPLAIN" (si manualul de SQL langa tine) vezi de ce si ce se poate face. -- Mihai RUSU Email: [EMAIL PROTECTED] GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net "Linux is obsolete" -- AST _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
