Memcached, echt zo'n groot verschil? - Linux en overige clients

zondag 9 augustus 2009 14:43

Acties:

Topicstarter

Zoals jullie aan de topic titel inmiddels kunnen zien heb ik een aantal kleine vragen omtrent het hele memcached gebeuren, ik heb het dus geïnstalleerd op aanrading van een bekende die wel eens wat met veel servers werkt.

Ik zal het even wat uitgebreider uitleggen:
Ik heb sinds kort mijn eigen VPS voor mijn eigen spel die ondertussen bijna af is, mij is dus aangeraden om memcached te gebruiken zodat alles iets sneller kan gaan, zal even mijn setup wat duidelijker maken:

VPS informatie:
CPU: 1,8GHz AMD64,
Geheugen: 1024MB (50mb in gebruik (idle)),
HDD: 80GB (2GB in gebruik),
OS: CentOS 5.2 (2.6.18-128.2.1.el5)

Mij werd dus gezegd dat ik memcached bijvoorbeeld zowel voor sessie managment kan gebruiken als voor 'PHP cache', alleen merk ik er totaal niets van. Heb de database classe eens omgebouwd naar één met memcache support, dit wordt ook opgeslagen (gecontrolleerd door memcache.php 'by Harun Yayli') maar alleen is het verschil voor mij niet waar te nemen.

Heb hem dus een paar dagen geleden ook op session-handler gezet, in eerste instantie wat problemen maar later toch nog even gefixt (starten wou niet, libevent moest even naar een andere versie). Nu zijn er dus een aantal problemen, net of de 'write' procedure wordt tegengehouden.

Zoals in mijn geval: phpBB doet moeilijk met sessies opslaan en hetzelfde als mijn zelf gemaakte CMS, het lijkt net of de sessies totaal niet worden opgeslagen, aangezien ik ze echt nergens terug zie. Als ik nu bij 'de stats' kijk zoals de 'hit / misses': Zie ik bijvoorbeeld al staan:

Current Items(total):	349 (2084)
Hits:	696
Misses:	193
Request Rate (hits, misses):	0.00 cache requests/second
Hit Rate:	0.00 cache requests/second

php.ini settings (sessions):

code:

1
2
3

[Session]
session.save_handler = memcache
session.save_path = "tcp://127.0.0.1:11211?persistent=1&weight=1&timeout=1&retry_interval=15"

Dus ik vraag me af of dat bij iedereen hetzelfde is, dat alles niet wordt opgeslagen. Heb er ondertussen al heel uitgebreid naar lopen te zoeken (ook op Google ed.) maar verder kwam ik niet echt.

Verder is mijn vraag nog even (dit is de laatste

), maakt memcache nou dus echt zo'n gigantisch verschil uit als je bijvoorbeeld per dag 100/1000 bezoekers op de site hebt?

Alvast bedankt!!

dinsdag 11 augustus 2009 03:45

Acties:

Verwijderd

Manueltje22 schreef op zondag 09 augustus 2009 @ 14:43:
Verder is mijn vraag nog even (dit is de laatste ), maakt memcache nou dus echt zo'n gigantisch verschil uit als je bijvoorbeeld per dag 100/1000 bezoekers op de site hebt?

Nee. Bij 1000 wordt het misschien wel nuttig, maar dat moet je een beetje van geval tot geval bekijken denk ik. memcache heeft in ieder geval vooral zin als je database het druk heeft. Hij houdt het resultaat van een query dan lekker in z'n geheugen en als dezelfde query weer langskomt kan de data direct uitgespuugd worden zonder die eerst weer bij de database te moeten opvragen. Prima oplossing dus als je het druk krijgt en er vaak dezelfde query wordt uitgevoerd, maar als je nog aan het testen bent zul je daar weinig van merken.

En dan dat andere ding: memcache gebruiken om je sessies op te slaan lijkt me wat zinloos als je niet aan load balancing doet, dus ik zou dat deel gewoon lekker schrappen.

dinsdag 11 augustus 2009 10:30

Acties:

Manuel

Topicstarter

Heb daar inderdaad al veel over gelezen maar tot nu toe echte benchmark's heb ik niet gezien, alleen zou het in theorie sneller zijn. Heb ondertussen even wat een oudere versie van memcache draaien en daar ramt hij de sessies wel goed in. PHPBB doet alleen nog moeilijk, dus dat wordt even snel een mod schrijven voor de code.

Maar wat nou als ik in de toekomst wel aan load-balancing ga doen aangezien het te druk wordt op de server, gaat het dan geen conflict opleveren of zelfs een prestatie-nadeel? Heb het nu in ieder geval al ingesteld als voorzorg. Als iemand verder nog tips / opmerkingen heeft, zie er naar uit!

dinsdag 11 augustus 2009 10:42

Acties:

Verwijderd

Linux cachet automatisch bestanden in (het vrije deel van je) ram. Met "free -m" kan je zien hoeveel linux nu als buffers/cache gebruikt. Eigenlijk bepaal je met memcache juist wat linux of de databaseserver moet cachen, dit zijn dan vaak dingen die elke request worden aangeroepen. Je kan van je session save path en je hele website ook een ramdisk maken, alhoewel dat misschien niet slim is op een vps.

Met loadbalancing heb je meerdere webservers, dan zou je memcached replication aan moeten zetten op iedere webserver. Het gaat er echter niet om hoeveel bezoekers je per dag moet verwerken, want dit is een hele lange periode. Je moet kijken hoeveel requests je in een kortere tijd (bijvoorbeeld een seconde) moet verwerken wanneer het druk is.

Als je een hele snelle site wil hebben kan je een caching reverse proxy gebruiken zoals http://varnish.projects.linpro.no/ . Deze kan mijn pagina's binnen 40ms leveren binnen mijn eigen netwerk.

dinsdag 11 augustus 2009 10:49

Acties:

Voutloos

Memcached gebruiken puur als query cache is wel heel naief. Andere zaken, en zeker groterecomplexere blokken data cachen ga je veel meer mee winnen.

En om te zien wat er te winnen valt moet je eerst profilen. En dat lijk je nou net overgeslagen te hebben.

[ Voor 3% gewijzigd door Voutloos op 11-08-2009 11:06 ]

{signature}

dinsdag 11 augustus 2009 10:58

Acties:

Manuel

Topicstarter

Verwijderd schreef op dinsdag 11 augustus 2009 @ 10:42:
Linux cachet automatisch bestanden in (het vrije deel van je) ram. Met "free -m" kan je zien hoeveel linux nu als buffers/cache gebruikt. Eigenlijk bepaal je met memcache juist wat linux of de databaseserver moet cachen, dit zijn dan vaak dingen die elke request worden aangeroepen. Je kan van je session save path en je hele website ook een ramdisk maken, alhoewel dat misschien niet slim is op een vps.

Met loadbalancing heb je meerdere webservers, dan zou je memcached replication aan moeten zetten op iedere webserver. Het gaat er echter niet om hoeveel bezoekers je per dag moet verwerken, want dit is een hele lange periode. Je moet kijken hoeveel requests je in een kortere tijd (bijvoorbeeld een seconde) moet verwerken wanneer het druk is.

Als je een hele snelle site wil hebben kan je een caching reverse proxy gebruiken zoals http://varnish.projects.linpro.no/ . Deze kan mijn pagina's binnen 40ms leveren binnen mijn eigen netwerk.

Hartelijk bedankt voor dit stukje informatie, heb er inderdaad al veel over gelezen. Alleen kan het misschien wat raar overkomen, maar bij free -m staat dat er 845MB in gebruik is terwijl er bij VMWare Control Panel (web) dat er maar 55MB in gebruik is, een gigantisch verschil als je het zo ziet. Ik zou dus zo even 1,2,3 niet weten van welke waarden ik moet uitgaan.

Verder wat je zegt over sessies met de ramdisk, heb ondertussen al een ramdisk aangemaakt en wil het dus eens een keer proberen, dus een soort test-case hier thuis opstellen om zo te kijken wat nou sneller gaat. (Virtuele pc's zijn zo aangemaakt).

En biedt Lighttpd standaard geen ondersteuning voor 'server-stats', dat per de status module dacht ik. Aangezien ik hier ook als HTTPD lighttpd heb draaien, werkt in ieder geval al een stukje sneller dan met Apache2.2 , plus de config is wat flexibeler als je het mij vraagt.

Ik ga ondertussen eens wat uittesten op de server, waarschijnlijk even profilen om zo toch eens tot een uiteindelijke conclusie te kunnen komen.

@Voutloos, wat bedoel je dan precies met grote blokken data, wat houdt dat precies voor jouw in? Graag een beetje meer informatie.

dinsdag 11 augustus 2009 11:11

Acties:

Voutloos

Je bent dus als een kip zonder kop aan het optimaliseren. Profile eens. Dan zie je bijvoorbeeld dat je veel tijd kwijt bent aan een groep van acties, en cache je die het totale resultaat ipv alle losse actietjes. Juist met dergelijke zaken valt veel te winnen. En misschien zie je uberhaupt tijdens het profilen dat je bepaalde onnodige zaken doet. Etc. etc.

Meten = weten. Gokken = tijd verdoen.

{signature}

dinsdag 11 augustus 2009 11:29

Acties:

Verwijderd

Meten kan je prima doen met "ab" (Usage: ab [options] [http[s]://]hostname[:port]/path). Ik denk dat je inderdaad beter af bent met een grotere query cache in bijv. mysql. Lighttpd gebruik ikzelf alleen voor static content, maar is ook prima te gebruiken met bijv. php.

"free -m staat dat er 845MB in gebruik is" -> je hebt denk ik de waarde inclusief de cache/buffers genomen.

code:

             total       used       free     shared    buffers     cached
Mem:          5880       5776        103          0        608       1551
-/+ buffers/cache:       3616       2263 <-- Deze moet je hebben
Swap:         8644          0       8644

Maar je website wordt sneller als je mod_expire, mod_compress etc aanzet. Zie YSLOW+firebug plugins voor firefox. Zie https://developer.yahoo.com/yslow/ en http://code.google.com/p/lighttpd-improved/

Met php debug en bijv. http://kcachegrind.sourceforge.net/html/Home.html kan je zien hoe lang php over verschillende onderdelen doet.

dinsdag 11 augustus 2009 11:47

Acties:

Manuel

Topicstarter

@Voutloos, als je mijn reactie had gelezen wist je dat ik daar aan begonnen ben

Verwijderd schreef op dinsdag 11 augustus 2009 @ 11:29:
Meten kan je prima doen met "ab" (Usage: ab [options] [http[s]://]hostname[:port]/path). Ik denk dat je inderdaad beter af bent met een grotere query cache in bijv. mysql. Lighttpd gebruik ikzelf alleen voor static content, maar is ook prima te gebruiken met bijv. php.

"free -m staat dat er 845MB in gebruik is" -> je hebt denk ik de waarde inclusief de cache/buffers genomen.
code:
1
2
3
4
             total       used       free     shared    buffers     cached
Mem:          5880       5776        103          0        608       1551
-/+ buffers/cache:       3616       2263 <-- Deze moet je hebben
Swap:         8644          0       8644
Maar je website wordt sneller als je mod_expire, mod_compress etc aanzet. Zie YSLOW+firebug plugins voor firefox. Zie https://developer.yahoo.com/yslow/ en http://code.google.com/p/lighttpd-improved/

Met php debug en bijv. http://kcachegrind.sourceforge.net/html/Home.html kan je zien hoe lang php over verschillende onderdelen doet.

Verder weer een mooie posting, alleen dat CentOS standaard geen ab ondersteunt, dan moet ik Apache gebruiken als ik sommige Google resultaten moet geloven. De database heeft in ieder geval heel wat query's te verduren wat dat betreft, per 'venster' (alles = nu nog even gescheiden) ongeveer 2 JOINS.

code:

total       used       free     shared    buffers     cached
Mem:          1010        848        162          0        178        467
-/+ buffers/cache:        202        808
Swap:         2047          2       2045

Ondertussen heb ik al een aantal keer de lighttpd documentatie doorgenomen (evenals forum) om wat te zoeken naar kleine optimalisaties, zowel op het PHP gebied als op het HTTPD gebied. Verder zijn de resultaten van MySQL (zojuist even heel wat quey's zitten uit te voeren, dan de results terug geven met SHOW PROFILE; toch best goed).

Initialisation is met een * bijvoorbeeld 0.000144 en zonder (dus ook alle rows): 0.000107. Ondertussen ga ik eens verder zoeken op internet van hoe en wat.

En heb zojuist ook even httpd_load gedownload, om lighttpd eens te testen, ik ga de resultaten noteren en dan kijken of ik het kan optimaliseren (of juist slechter maken

) Bedankt alweer voor je leuke post!