Du ser Jeg kører et websted, der gør UFC forudsigelser og UFC resultater. På Fight Night, kan sitet få temmelig travlt, min tidligere højt var 18.000 besøgende i de 3 eller deromkring timer at kampene finder sted. Min delt hosting-konto aldrig havde et problem med denne belastning, i hvert fald ikke så vidt jeg kunne fortælle. Men med UFC 77 på min nye dedikeret hosting konto min server ramt en mur. CPU var på 100%, og der var 200 apache processer alle kappes om den tilgængelige CPU og hukommelse. Straks jeg begyndte at lede efter årsager og endnu vigtigere løsninger.
Tre dage senere tror jeg, jeg har de fleste af mine answers.It er vigtigt at vide, at Go Daddy var uden skyld, jeg bad om en kasse med visse specs, og det er præcis, hvad de gav mig, komplet med al den software, de sagde. MySQL, phoP 4.3.9 og Apache 2.0.52. Så jeg begyndte at kigge (når serveren dulmer) ved, hvad der skete, når en bruger anmodet om en side. Den første ting, jeg bemærkede var, at den nuværende apache processen ville tage omkring 5% CPU, jeg ikke er opmærksomme på, hvor lang tid det løb.
Det næste jeg bemærkede var, at MySQL også ville tage betydelig CPU, hvis det kun for en kort periode. Det er vigtigt at vide, at i løbet af UFC 77 MySQL tog ca 50% CPU for hele travle periode. Tid til at søge efter nogle optimizations.For mit site, hvor der er 20.000 besøgende i 3 timer og måske 10 opdateringer i løbet af denne tid, ville caching naturligvis være nyttigt. Jeg lagde mærke til at søge på nettet, som apache har nogle caching og endnu bedre nogle min caching, men det anses ikke for produktionen klar i 2.0.52 build, som jeg har, så jeg kasseret den idé ret hurtigt.
Jeg dog bemærke nogle ting, når jeg kiggede på MySQL optimizations.The vigtigste MySQL optimering, som jeg fandt er query_cache_size mulighed. Ser du, MySQL har dette koncept for forespørgsel caching, her er en simpel forklaring. Hvis jeg gør en simpel forespørgsel, saySELECT CUSTOMER_NAME fra kunden, hvor CUSTOMER_ID> 10 (jeg ved, en dum forespørgsel) Generelt databasen går gennem alle det er magi og returnerer tilbage resultatet sæt af alle kunder navne Hvem er id er større end 10.
Til denne forespørgsel det ville ikke tage meget lang tid, men jo mere kompleks forespørgslen jo længere det ville tage. Men med MySQL query caching, resultatet af denne forespørgsel vil blive holdt i hukommelsen, sammen med forespørgslen selv, hvilket betyder, at næste gang den samme forespørgsel blev kørt databasen ville blot kontrollere, at ingen tabeller i forespørgslen er blevet ændret, og derefter se op resultatet i hukommelsen og give det tilbage. Dette er meget hurtigere.
MySQL har query caching aktiveret som standard, men query_cache_size variablen er sat til 0, hovedsagelig deaktivere funktionen. At tænde den du skal gøre: query_cache_size = 64M i my.cnfNote: Jeg steg også min query_cache_limit til 4 M og min thread_cache_size til 384. Der er mange andre MySQL indstillinger, som du kan indstille til at forbedre ydeevnen, kigge efter en god MySQL bog eller måske vil jeg sende nogle af dem på min open source depot blog på www.open-source-depot.com/blog.After fastsættelse af disse muligheder i my.
cnf du bliver nødt til at genstarte MySQL, er, at jeg er lidt utålmodig og jeg kan ikke lide genstart processer Jeg gik til MySQL kommandolinjen og sat de globale muligheder. Af en eller anden grund 64M ikke virkede for mig der, så jeg brugte den udvidede (bytes) versioni.e mysql> SET GLOBAL query_cache_size = 60.000.000, til at se, hvad der indstillet, gøre en: mysql>