Apache 1.3x en lokale proxy voor acceleratie

[Wunk]

Situatie:

We hebben een klant met een dedicated server waar een erg zware site op draait welke flink in de groei heeft gezeten en nog steeds zit, deze site gebruikt veel PHP en MySQL.. (forum, dynamische content, logging van stats naar mysql, enz..)

Nu heb ik eens een verhaal gehoord waar je apache lokaal kunt laten proxyen om de content geproxied aan te leveren en dus een deel van de load van het parsen van PHP scripts van de server al kunt vermijden en apache dus kunt ontzien.

Alleen kan ik hier gewoon verdomd weinig over vinden (zo'n beetje alle proxyverhalen komen neer op 2e machines e.d.)

Of zijn er nog wat andere acceleratietips mbt. PHP en MySQL ?, Turck_MMCache heb ik al geprobeerd, maar dit helpt bijna niks (druppel op de gloeiende plaat), MySQL hebben we al geprobeerd te optimizen, maar dat loopt nu ook op z'n einde, en ik wil even weten of ik echt out of options ben voor ik de klant definitief aanraad een zwaardere server aan te schaffen ('t geheel draait nu op een P4 2.8Ghz met 2x80GB Sata op raid-1 en 1GB ram)

De server behandeld tijdens de piekuren naar schatting zo'n 35-40 requests per seconde, waarbij de apache request queue af en toe boven de 150-200 komt. (ik moet even schatten, want ik heb de getallen nu zo niet bij de hand)

[jongetje]

http://www.squid-cache.org/

[Verwijderd]

ob_start etc werken ook prima en simpeler. http://nl2.php.net/manual/nl/function.ob-start.php

Probeer ook eens eaccelerator, dat is een phpaccelerator die ervoor zorgt dat de phppagina's niet constant geparsed moeten worden, maar dat er een kopie in het shared memory aanwezig blijft. Het is trouwens een fork van Turck met een aantal extra patches. Maar als dat een druppel op een gloeiende plaat is, ga dan eens naar het dbontwerp kijken. Indexen nalopen, etc. Vermijdt SELECT * FROM blaat bijvoorbeeld.

Ik heb overigens geen idee wat de rest van de belasting van je server is, maar voor een gecombineerde dbase + webserver gaan 1GB wat krap zijn. Kijk voor de rest eens naar de stats van je machine, mysql voornamelijk. Staan de caches goed, keybuffer groot genoeg, etc

Kortom, als je wil optimaliseren moet je of ons meer informatie geven, óf zelf aan de slag. Voor dat proxyen kan je prima de geintegreerde opties van php gebruiken in plaats van de proxy

En om even een gigantische lap tekst te besparen, lees dit even. Zeer goede tips voor de optimalisatie van web/dbase combi's Groot verhaal van Femme op Fok

Nooit gedacht dat ik hiervoor naar Fok zou doorverwijzen
_{Mocht je daar gebanned zijn, zeg het even, dan quote ik het hier voor je}

[ Voor 94% gewijzigd door Verwijderd op 30-03-2005 17:28 ]

[Wunk]

Er zou inderdaad nog wat geheugen bij kunnen, er word zo'n 300MB geswapt momenteel..

Ik ga de klant eens even vragen of hij ob_start in z'n site(s) gebruikt, want z'n php heb ik niet zitten doorspitten..

De SELECT * statements heeft 'ie als 't goed is al een maand of 2 er uit gegooid, want dat heb ik 'em toen ook al aangeraden..

Dit is hoe de my.cnf er op dit moment uit ziet:

[safe_mysqld]
open_files_limit = 8192

[mysqld]
query-cache-size = 256M
skip-innodb
set-variable = key_buffer=16M
set-variable = key_buffer_size=1500
set-variable = max_allowed_packet=1M
set-variable = thread_stack=128K
set-variable = query_cache_limit=1M
set-variable = query_cache_size=128M
set-variable = query_cache_type=1
set-variable = table_cache=1024
set-variable = myisam_sort_buffer_size=64M
set-variable = thread_concurrency=2
set-variable = thread_cache_size=50

[isamchk]
set-variable = key_buffer=64M
set-variable = sort_buffer=64M
set-variable = read_buffer=16M
set-variable = write_buffer=16M

[myisamchk]
set-variable = key_buffer=64M
set-variable = sort_buffer=64M
set-variable = read_buffer=16M
set-variable = write_buffer=16M

Bedankt voor die URL's, ik ga de klant even aan 't zoeken zetten in z'n eigen code ('t word of zoeken, of een dual xeon met 15k SCSI schijven kopen)

[ Voor 4% gewijzigd door Wunk op 31-03-2005 09:56 ]

[Verwijderd]

Het handigste is ook om wat timers op die site in te bouwen om te zoeken waar precies de bottlenecks liggen, zet het slow-log van mysql eens aan het kijk wat er daar in komt te staan. Post hier anders even wat statistieken van phpmyadmin, onderaan de statuspagina staat een boel handige info. Zelfde geldt voor free -m bijvoorbeeld, wat doet de load van je bak, etc.

Ik weet niet wat de rest van die server doet, maar 15K scsi schijven is vaak niet nodig, een goede SATA RAID controller met wat raptors is ook erg rap

Ik zou echt ook even kijken naar een extra strip van 512MB, dat zijn de kosten niet. Voor een gecombineerde webserver/dbaseserver is 1GB erg krap. En helpt het niet, breng je de strip geheugen weer terug

Overigen zijn dit soort dingen



ook altijd errug handig om eens te kijken wat er nou precies gebeurt Dit is een zelfgeschreven iets, maar het kan ook met MRTG / Cricket bv.

[ Voor 35% gewijzigd door Verwijderd op 31-03-2005 10:29 ]

[Wunk]

Created tmp disk tables 108244
Created tmp tables 730557
Created tmp files 92
Delayed insert threads 0
Delayed writes 0
Delayed errors 0
Flush commands 1
Handler commit 0
Handler delete 3003762
Handler read first 41104
Handler read key 3779228440
Handler read next 1102426714
Handler read prev 70818
Handler read rnd 390507301
Handler read rnd next 1546079484
Handler rollback 0
Handler update 2662375549
Handler write 937192610
Key blocks used 0
Key read requests 3587618661

Variable Value
Key reads 3587618661
Key write requests 37388169
Key writes 37388169
Max used connections 100
Not flushed key blocks 0
Not flushed delayed rows 0
Open tables 1022
Open files 1292
Open streams 0
Opened tables 1472
Qcache queries in cache 18059
Qcache inserts 8144655
Qcache hits 49822685
Qcache lowmem prunes 109977
Qcache not cached 231657
Qcache free memory 91407136
Qcache free blocks 12352
Qcache total blocks 49161
Rpl status NULL

Variable Value
Select full join 110384
Select full range join 2
Select range 48840
Select range check 0
Select scan 4514749
Slave open temp tables 0
Slave running OFF
Slow launch threads 43
Slow queries 4876
Sort merge passes 46
Sort range 553117
Sort rows 468283718
Sort scan 2355301
Table locks immediate 40895510
Table locks waited 508446
Threads cached 47
Threads created 6659
Threads connected 3
Threads running 1

En we monitoren de boel al met snmp icm cacti, in de piekuren komen er af en toe loadspikes tot rond de 20-30




't is overigens geen SATA, (iets oudere generatie Dell, de PE650) maar ATA met een PERC/CERC ATA raid card.. (16MB buffer geloof ik) op een raid-1 config..

[Wunk]

Even toevoeging op de raid instellingen:

CERC ATA100/4ch card
DRAM= 16MB
Write policy = WRTHRU
Read policy = Adaptive (kan ook op Redahead of No readahead worden gezet)
Cache policy = DirectIO (als alternatief kan CachedIO worden ingesteld)

[Wunk]

De free -m:

code:

             total       used       free     shared    buffers     cached
Mem:          1006        922         83          0         54        433
-/+ buffers/cache:        434        572
Swap:         2000        258       1741

[ Voor 4% gewijzigd door Wunk op 31-03-2005 11:17 ]

[Verwijderd]

hmm, toch lijkt het erop dan er genoeg geheugen vrij is atm. Het aantal SELECT scan's is wel vrij heavy, toch eens je indexxen nakijken lijkt me een goede tip

Zoals we op msn al zeiden, pak even de stats erbij wanneer het flink druk is Het is nu nogal rustig zei wu

Sander - Eerste studiepunten binnen zegt:
welke mysql versie gebruik je?
Wunk @ Work zegt:
4.0.21

Sander - Eerste studiepunten binnen zegt:
hoe groot is de dbase ca?
Wunk @ Work zegt:
544MB, forum zo'n 150MB

/me gaat tentamen maken, geen tijd om nog verder te lezen / reageren

[ Voor 71% gewijzigd door Verwijderd op 31-03-2005 11:30 ]