Load omlaag helpen op high traffic server.

[Jamai]

Ik heb een server die nogal veel bezoekers heeft. Dagelijks zitten er 20.000 unieke bezoekers, wat natuurlijk nog niet veel is, maar de site bevat een (lightweight) forum en mensen kunnen elkaar berichten sturen. Soort van Fok!-achtige website in elk geval.

Op de piekuren zitten er 800 ingelogde mensen die bij elkaar duizendenpagina's bekijken; gemiddeld worden er 40 pagina's per bezoeker bekeken en dan kom je dus uit op dichtbij de miljoen dynamische (!) pageviews.

Nu heb ik me zitten verdiepen in manieren om de load wat omlaag te halen. De server zit geregeld tussen de 10-20 aan load, gelukkig wel nog 40% idle meestal dus alles wordt nog wel snel afgehandeld.

Ik draai met de nieuwste PHP5, de nieuwste Apache2 en de nieuwste MySQL 4. Natuurlijk wel allemaal de stabielste nieuwste versies

Hardware: Dual Xeon 3.0 Ghz met hyperthreading, 2x 200 GB hardeschijven in (hardware) RAID1, 4 GB DDR2-geheugen

Ik vraag me op dit moment heel erg af of een 2e webserver installeren voor statische content een slim plan is. Op elke pagina staan wel 30-40 images. Ik hoorde dat TUX, khttpd, en thttpd hier goed in zijn. Iemand hier ervaringen mee?

Verder valt er waarschijnlijk aan Apache nog wel het 1 en ander te tweaken aan deze instellingen:

Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 3

<IfModule prefork.c>
ServerLimit 1152
StartServers 128
MinSpareServers 20
MaxSpareServers 40
MaxClients 1152
MaxRequestsPerChild 0
</IfModule>

Hoe kun je bepalen wat hier de beste instellingen zijn? MaxClients & ServerLimit zijn denk ik wel goed ingesteld, aangezien ik tijdens piekuren rond de 1050 clients waargenomen heb.

MySQL levert waarschijnlijk de grootste belasting. Alle queries zijn al geoptimized, heb hier ook uitgebreid mee getest en alles op de beste manieren staan nu (ook qua indexen, keys, en een aantal databases in InnoDB omdat die continue geupdate moeten worden).

De instellingen van MySQL heb ik niet zelf gemaakt, en heb hier dan ook grote twijfels over:

[mysqld]
set-variable=max_connections=1000
port = 3306
socket = /tmp/mysql.sock
skip-locking
key_buffer = 128M
max_allowed_packet = 16M
thread_stack = 128K

table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache = 8

query_cache_limit = 1048576
query_cache_size = 32M
query_cache_type = 1

thread_concurrency = 8
skip-networking
skip-bdb

Voor het InnoDB gedeelte geldt hetzelfde:

innodb_buffer_pool_size = 768M
innodb_additional_mem_pool_size = 20M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

Voor de volledigheid de rest van my.cnf:

[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[isamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
[myisamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

max_connections=2000

Hoe bepaal je dit soort waardes?

PHP is gecompileerd (ook al weer niet door mij) met de volgende modules:
core mod_access mod_auth mod_log_config mod_env mod_setenvif prefork http_core mod_mime mod_status mod_autoindex mod_asis mod_negotiation mod_dir mod_imap mod_actions mod_userdir mod_alias mod_so mod_include mod_cgi mod_speling mod_rewrite mod_php5

En Zend Optimizer heb ik er zelf opgezet in de hoop alles nog iets te versnellen.

Verder werk ik dus met sessies voor elke gebruiker die ingelogd zit. Valt hier op de één of andere manier nog een winst te boeken?

[WH-Tim]

Kun je niet beter eens naar de methode van weblogs als Geenstijl e.d. kijken hoe deze werken? Deze hebben ook inmens veel pageviews en doen volgensmij niet voor elke pageview een grote query draaien. Denk dat na het posten van een reactie oid een nieuwe output .html genereren een goed idee zal zijn om mysql connections / load problemen op te lossen.

[NextIT]

Origineel geplaatst door WH-Tim
Kun je niet beter eens naar de methode van weblogs als Geenstijl e.d. kijken hoe deze werken? Deze hebben ook inmens veel pageviews en doen volgensmij niet voor elke pageview een grote query draaien. Denk dat na het posten van een reactie oid een nieuwe output .html genereren een goed idee zal zijn om mysql connections / load problemen op te lossen.

Dat is leuk voor een site met heel veel statische pagina's, maar niet voor een forum zoals TS beschrijft.

[Jamai]

Dat is inderdaad precies het probleem: De pagina van elk ingelogde lid ziet er anders uit. Gaat hier dus niet echt op.

Waar mogelijk schrijf ik ook gewoon .html pagina's weg, zoals de verjaardagen-kalender (die update in 1x per dag, om 0:01).

Ook de reakties zijn al gecached, m.u.v. het forum (maar daar komt de werkelijke load niet vandaan)

[Deimos]

Je geeft aan dat het forum niet voor de werkelijke load zorgt. Welk onderdeel doet dit dan wel?

Verder ben ik benieuwd welk OS je gebruikt en welke versie. De opties die jij overigens noemt als onderdeel van PHP zijn onderdeel van Apache. Je zou kunnen bekijken welke modules je niet gebruikt en deze disablen.

[Jamai]

Het is niet 1 onderdeel. Telkens als ik merkte dat er op 1 onderdeel problemen waren heb ik tabellen beter genormaliseerd, betere keys aangebracht, betere queries gemaakt e.d.

Het is dus meer dat er zo massaal bezocht wordt dan dat er echt iets zwaars uitgevoerd wordt (ja oke, het images resizen na een upload met gdlibrary is redelijk zwaar).

Die modules zal ik nog even naar kijken, even uitzoeken wat het allemaal doet nog

[wonko]

Je zal moeten uitzoeken wat vooral de load veroorzaakt. Kijk eens moet iostat als bvb de harddisks snel genoeg zijn, en de data snel genoeg kunnen aanleveren. Als dit het probleem is, dan ga je naar een andere opslagoplossing moeten zoeken. MySQL en Apache data laten laden van dezelfde disks kan nefast zijn.

Zet een slow-query log op in MySQL en gebruik dat om slechte queries te vinden. Kijk in de processlist van mysql welke queries veel tijd vergen, en probeer deze te optimalizeren.

Je moet gewoon zoeken welke processen in de wachtrij zitten, hoelang ze er zitten, en wat zorgt voor die "traagheid".