Precies, nu.nl zal ongetwijfeld caching van queries EN paginas gebruiken.
Wat ik wel zeker weet is dat ze een paar jaar geleden een reverse proxy hadden lopen.
Afdrukvoorbeeld
Precies, nu.nl zal ongetwijfeld caching van queries EN paginas gebruiken.
Wat ik wel zeker weet is dat ze een paar jaar geleden een reverse proxy hadden lopen.
Ja, dat heb ik me altijd af zitten vragen bij memcached: als ik om wat voor reden dan ook alle memcached instanties moet herstarten, krijg je het systeem dan wel weer gestart, of stort het bij elke herstart in? Stel je voor: power strip defect, alle memcached's uit. Na de herstarts zijn alle instanties leeg en moet alle data even uit de database komen.
Is het niet handiger om een cache te gebruiken die eventueel van disk gestart kan worden?
Kees Jan
Sorry voor de iets te laten reactie:
FE#1: Queries per second avg: 159.177
FE#2: Queries per second avg: 159.216
FE#3: Queries per second avg: 177.483
FE#4: Queries per second avg: 177.385
Backend: Queries per second avg: 51.888
@Ramon, de reverse proxy [wodan] is vervangen door Varnish.
Tweakers.net draait anders ook op een major database server. Geen idee hoeveel queries per sec, maar dat zullen er heel wat zijn.
Er is ook heel veel gecached hoor =)
Zie hier hun stats: http://tweakers.net/stats/
serverstats: http://tweakers.net/stats/?Action=Serverstats
Goed gebruik maken van memcache forests ;)
Daardoor kan je memcache servers plat gooien zonder dat de boel in stort.
Als de gehele feed plat gaat, gaat de rest ook uit, dus dan kan het ook niet meer instorten :p
Jullie ook varnish :):)Citaat:
Oorspronkelijk geplaatst door Bhai
Top pakket hé?
Wij hebben nu een clustertje draaien van 8 servers X 48GB geheugen die uit malloc serveren. Ik heb ook redelijk contact met Paul ;). Misschien kunnen we een beetje kennis uitwisselen hierover. Ik heb er namelijk redelijk wat tijd in varnish verdiept en neem aan jullie ook. Mogelijk levert het iets op. Neem hiervoor maar contact met mij op via pb, dan kunnen we mail adressen uitwisselen.
Dag QBell,
Memcache forests? Heb je meer info?
Kees Jan
Wij hebben een daemon geschreven die een tcp poortje open houd en requests ontvangt van mysql en php. Deze chunkt vervolgens de data (bij meer als 1MB) en schrijft dit redundant weg over verschillende memcache servers.
Hierdoor hebben we altijd 2 chunks staan ergens en mag er willekeurig 1 uitvallen zonder problemen.
De uiteindelijke latency is een paar ms hoger geworden door deze C applicatie die er tussen staat, maar het overall plaatje is er wel vele malen beter door geworden.
Hmmm. Interessant, want je lost twee problemen tegelijk op. Is de source code daarvan beschikbaar?
Kees Jan
Ik zal hier intern is overleggen of we de source code beschikbaar gaan stellen.
Ligt er een beetje aan hoeveel support tijd de programmeur hierin wil steken.
Support is niet nodig. We hebben hier genoeg C devs lopen. :)
Doorgeven aan jou alleen is nog geen open source ;)
Ik ken iemand die hardnekkig probeert meer dan 17000 qps te doen op een mysql-slave die enkel dat inserts/updates doet. Hij geraakt niet echt veel verder dan 17000 momenteel.
@frankske
het is wel mogelijk om meer te doen, maar niet met een simpele raid5 diskset.
Je kan kijken naar tablespace in mysql [5.1] met tablespace kun je tabellen op eigen disksets krijgen en hoe sneller je deze schijven krijgt [bijv met raid10 met 20 schijven of meer <- per tabel of index :)] des te meer queries per seconde je krijgt
Er is wel een groot probleem met deze setup, het gaat je belachelijk veel geld kosten.
Er zijn wedstrijden, combinatie van hardware/software, welke opzet de meeste transacties per minuut kan verwerken. Vorige maand kwam er een nieuwe nummer 1 met 7,646,486 transacties per seconde.
Helaas heb ik dit nog niet gezien voor MySQL [best jammer].
http://www.tpc.org/tpcc/results/tpcc...p?id=109110401
Onderaan vind je 2 PDF's , de eerste is de factuur :) de 2e complete stappen plan van de setup en hoe en wat, maar er staat niet in waarom de developers gekozen hebben voor bepaalde indexes etc en waarom ze bepaalde queries zo hebben geschreven.