Du ser Jeg kjører en nettside som gjør UFC spådommer og UFC resultater. På fight night, kan området bli ganske travelt, min forrige høy var 18.000 besøkende i 3 timer eller så at kampene foregår. Min webhotell aldri hatt et problem med denne belastningen, i hvert fall ikke så vidt jeg kan fortelle. Men med UFC 77 på min nye dedikerte hosting konto serveren min traff en murvegg. CPU var på 100%, og det var 200 apache prosesser alle kjemper for det tilgjengelige CPU og minne. Straks jeg begynte å lete etter årsaker og enda viktigere løsninger.
Tre dager senere jeg tror jeg har det meste av min answers.It er viktig å vite at Go Daddy var ikke på feil, jeg ba om en boks med visse spesifikasjoner og det er akkurat hva de ga meg, komplett med all den programvaren de sa. MySQL, PHOP 4.3.9 og Apache 2.0.52. Så begynte jeg å se (når serveren roet ned) på hva som skjer når en bruker har bedt om en side. Det første jeg la merke til var at den nåværende apache prosessen vil ta ca 5% CPU, det gjorde jeg ikke ta hensyn til hvor lang tid det gikk. Det neste jeg bemerket var at mysql vil også ta betydelig CPU, om bare for en kort periode.
Det er viktig å vite at under UFC 77 MySQL tok ca 50% CPU for hele travle perioden. Tid for å søke etter noen optimizations.For nettstedet mitt, hvor det er 20.000 besøkende i 3 timer og kanskje 10 oppdateringer i løpet av den tiden, ville caching åpenbart være nyttig. Jeg la merke til å søke på nettet som apache har noen caching og enda bedre noen min caching, men det er ikke ansett produksjonsklar i 2.0.52 build som jeg har, så jeg forkastet den ideen ganske raskt. Jeg imidlertid merke til noen ting når jeg så på MySQL optimizations.
The viktigste MySQL optimalisering som jeg fant er query_cache_size alternativet. Du skjønner, MySQL har dette begrepet spørring caching, her er en enkel forklaring. Hvis jeg gjør en enkel spørring, saySELECT CUSTOMER_NAME fra kunden hvor CUSTOMER_ID> 10 (jeg vet, en dum spørring) Vanligvis databasen går gjennom alle det er magi og returnerer tilbake resultatet sett alle kundenes navn som er id-er er større enn 10. For dette søket det ikke ville ta veldig lang, men mer komplekse spørringen jo lenger tid det ville ta.
Men med MySQL spørring caching, resultatet av dette søket vil bli holdt i minne, sammen med selve spørringen, noe som betyr at neste gang den samme spørringen ble kjørt databasen ville bare sjekke at ingen tabeller i spørringen har blitt endret og deretter se opp resultatet i minnet og gi den tilbake. Dette er mye raskere. MySQL har spørring caching slått på som standard, men query_cache_size variabelen er satt til 0, i hovedsak deaktivere funksjonen. Å slå den på må du gjøre: query_cache_size = 64M i my.cnfNote: Jeg har også økt min query_cache_limit til 4M og min thread_cache_size til 384.
Det er mange andre MySQL alternativer som du kan angi for å forbedre ytelsen, se etter en god MySQL bok eller kanskje jeg skal legge ut noen av dem på min åpen kildekode depot blogg på www.open-source-depot.com/blog.After sette disse alternativene i my.cnf du trenger for å starte MySQL, er at jeg er litt utålmodig, og jeg liker ikke omstart prosesser jeg gikk til MySQL kommandolinjen og sette de globale alternativer. For noen grunn 64M ikke fungerte for meg der, så jeg brukte den utvidede (bytes) versioni.
e mysql> SET GLOBAL query_cache_size = 60000000, for å se hva som er satt, gjøre: mysql>