A Twitter Ruby on Rails-re íródott, amit a kifejezetten erre írt Mongrel webszerveren futnak (állítólag a leggyorsabb/leghatékonyabb RoR megoldás, nem tudom, én csak egy lesajnált PHP-s vagyok). A Twitter 180db RoR instance-t használ. (fogd fel afféle "virtuális" szerverként).

Az adatbázis-szerverük MySQL. Azért használ sok nagy webes szolgáltatás MySQL-t, mert olcsó és könnyű rá fejleszteni. Az igazi nagy cluster adatbázis-szerverek méregdrágák és felborítják a webkettes üzleti modellt. (A MySQL cluster üzemmódja sajnos nem elég jó, kell hozzá még pár verzió. Erről egy későbbi posztban majd, egyszer.)

Most figyelj: 1 db MySQL szerverük van (meg egy slave a statisztikákhoz és riportokhoz). Ha ezt a szervert használnák az adatbázis olvasásához, akkor egyáltalán nem tudnának működni: ez csak arra van, hogy tárolják az adatokat (insert/update/delete).

16GB-nyi memcached cache. A trükk itt van, memóriában tárolnak egy csomó mindent és így a lekérdezésekhez szinte egyáltalán nem kell a MySQL-t használni. Ez a megoldás egyre-másra terjed: van egyszem MySQL a perzisztens, merevlemezen tárolt adatokhoz és valamilyen elosztott-megosztott memóriás izé az olvasáshoz. A fürtözött IMDB - in memory database dolog hamarosan nagy buzz lesz, majd egy későbbi posztban erről is.

Az egész Twitter 8 db Sun X4100S vason fut. A MySQL-nek természetesen egy kimaxolt példányt adtak, 8 maggal meg minden.

Probléma?

A Twitter egy-adatbázisszerveres koncepciója a probléma. Szegény 2400 kérést kap minden másodpercben, tehát fullon megy. Hiába cache-elik az olvasásokat, a Twitter már van annyira népszerű, hogy az adatbázis írása szűk keresztmetszet. Hiába olyan egyszerű a Twitter adatbázisa, hogy egyetemistáknak is kiadható vizsgafeladatként a megtervezése (emlékszel, amikor a normalizálást próbálták belédverni?).

A saját bevallásuk szerint is akkor szokott lerohadni a rendszer, amikor sokan állnak neki sok follow-nak, azaz mikor sokan kezdenek követni, sokan kezdenek "barátkozásba". Ez nyilván több adatbázis-műveletet eredményez, mint egy szimpla Twitter status update.

Sokszor előfordul, hogy márketing célokból valaki kigyűjt néhány ezer Twitter felhasználónevet és follow-ra rakja. Az ilyenek mindig kiakasztják a rendszert, aztán a Twitteresek szépen kitörlik őket felhasználóstul-mindenestül.

Ha működik, így megy (átlagok)

600 feldolgozandó kérés érkezik másodpercenként, ebből csak 60 a Twitter saját oldala, a többi API kérés (third party alkalmazások, asztali olvasók meg kismillió mashup). A 600 kérés általában 2-300 kapcsolattól érkezik.

Egy kérést átlagosan 0.2 másodperc alatt szolgálnak ki, ami nagyon sok (egy szerver mindössze 3-4 kérést tud teljesíteni egyszerre...) Mutatja, hogy a rendszer teljesítőképességének határán dolgozik. Én éppen most optimalizálom az összes általam fejlesztett rendszert, és azok akkor válaszolnak 0.2 alatt, ha kiiktatok egy csomó optimalizálást.

Egy adatbáziskérést 0.05-0.1 másodperc alatt futtatnak le, ez megintcsak kábé tízszerese a jónak. Pengeélen táncolnak.

Sztorik, satöbbik

Nem mondják meg, hogy hány felhasználójuk van, csak annyit, hogy több mint 350e. Mivel meglehetősen aktív a táboruk, ezért feltételezhetően nincs annyi alvó account, mint mondjuk az iWiW-en.

Az SMS-ek küldésére költik a legtöbb pénzt, mert ehhez külsős SMS gateway-ek szükségesek, amik nagyon drágák. Ezek úgy működnek, hogy vagy egy API-n keresztül küldöd nekik a küldendőt, vagy e-mailt küldesz egy meghatározott címre és azt küldik tovább SMS-ben.

A kezdeti leállásoknál nem tudták mi van, mert elfelejtettek monitoring cuccot telepíteni, semmi statisztikájuk nem volt... a Twitter tényleg amatőr szintről indult és belefutottak szinte az összes elképzelhető skálázódási ügybe.

Később rengeteg felesleges időt töltöttek külsős fejlesztők tanácsainak kipróbálásával átütő eredmény nélkül, ezért most már inkább házon belül próbálják megoldani a problémákat.

Rájöttek, hogy nem az alkalmazott nyelvtől függ a teljesítmény, hanem az alkalmazás szerkezetétől. Hiába váltanának X nyelvről Y-ra, az a max. 20-30%-os haszon nem elég.

Nagyságrendekben kell gondolkozni.

Ha a webes dolgodhoz egy másodperc alatt átlagban több, mint 50 kérés esik be, ott egészen más szaktudásra van szükség, a "sima" fejlesztő már nem elég. Ha ez a szám több, mint 100, akkor még több skill kell. Sőt, a megoldandó problémák nagysága exponenciálisan nő.

Én hamarosan belefutok egy ilyenbe, ezért tanulom ezerrel a praktikákat és tolom a cloud computing-ot.

Magyarra lefordítva napi 50e látogatás (nem Webaudit-os fos view! igazi!) fölött már okosan kell, 100e fölött pedig hűha van. Ezen a szinten már egy lekérdezés megtervezése sem az SQL megírásából áll és minimum háromrétegű az adatok elérése (local cache, elosztott cache, adatbázis).

7 hozzászólás

1. idézem 2008.05.21. 05:23
   • wyctim
   Wow, mindig érdekelt mi mozog a Twitter mögött, kösz. :)
2. idézem 2008.05.31. 13:24
   • Hodicska Gergely
   Hát igen, mindig ott kezd meleg lenni a pite, amikor az írás eszi meg a mastert, akkor már nem elég a replika, jöhet a sharding, meg szívás, hogy lehet újra írni az alkalmazást, meg a kereszt, hogy a jövöben néha nagyon egyszerű dolgokat is majd csak munkásan lehet megoldani.
   
   A kérések száma önmagában nem minden, függ attól is hogy milyen célra, milyen struktúrában kell rögzíteni az adatokat, mennyire okozhat gondot a párhuzamosság, illetve hogy milyen izolációs szintre lehet szükség. Van olyan szerverünk amin van 900 insert másodpercenként, és vígan ketyeg.
   
   A 0,2 a szerintem brutál rossz (ezt merre olvastad?), én eléggé törekszem arra, hogy ha lehet, akkor 10-30 ms környékén legyen egy oldal, főleg a látogatottak. Épp most álltam neki framework redesignnak: fullos MVC rendszer, dinamikus routolással, symfonyra hajazó view réteggel 2-3000 hello word kérést ki tud tolni (ab -t 10 -c 30); session kezelést (meg még pár apróbb régi rendszerre jellezmő funkciót) bekapcsolva is 1100 kérés bírt, ami egyszerűbb kéréseknél (pl. ajax stb.) még gyorsabb is lehet.
   
   Üdv,
   Felhő
   
   u.i.: A weblap építés részbe írtam egy hosszabbat, de sajnos úgy tűnik, hogy elveszett, a cikk helyére maga a teljes oldal jött be. (Most már megvolt a Ctrl-A Ctrl-C :))
3. idézem 2008.06.02. 07:09
   • Gábor
   @felhő: Nem adom ki a forrásaimat, mert figyel a titkosszolgálat. :-)
   
   1100 kérés session-nel igen nice, akkor így production-ben talán meglesz a 400 is?
   
   Az viszont még mindig nagyon-nagyon érdekelne, hogy mit csináltok a ustream-nál akkor, ha egy adott stream-et egyszerre több ezren szeretnének nézni, hiszen erre a Red5 nem ad megoldást.
4. idézem 2008.06.02. 15:05
   • Hodicska Gergely
   "Nem adom ki a forrásaimat, mert figyel a titkosszolgálat. :-)"
   :), na jó, de akkor viszont kötelező mindent lebloggolni. :P
   
   "1100 kérés session-nel igen nice, akkor így production-ben talán meglesz a 400 is?"
   Hát ez oldal típustól is függ, meg hogy mennyire cizelláljuk. Remélem, hogy akár magasabb szám is lehet, még van pár ötletem a lehetséges optimalizálásra. Végülis egy "rendes" oldal esetén kicsit több kód lesz a templateben, meg plusz még pár memcache hívás az adatok előszedése...hát majd kiderül, hogy mit sikerül kifacsarni belőle, majd megírom.
   
   "Az viszont még mindig nagyon-nagyon érdekelne, hogy mit csináltok a ustream-nál akkor, ha egy adott stream-et egyszerre több ezren szeretnének nézni, hiszen erre a Red5 nem ad megoldást."
   A Red az ugye csak a felvett videók esetén érdekes: ez a rész most épp átalakulóban van, amit pl. megtehetsz, hogy maguk a fájlok replikálva vannak, és a lejátszó proginak egy gateway hívás adja meg, hogy épp melyik szerverről szedje a streamet, ezzel tudsz load balance-olni.
   
   Üdv,
   Felhő
5. idézem 2008.06.02. 23:25
   • Gábor
   @felho Két kérdés: live videóknál sok nézõ, azt hogyan? Felvettekhez minek Red?
6. idézem 2008.06.04. 02:08
   • xSolutions
   Kommenteltem itt, de eltünt a moderálandók között. Lehet tudni a sorsáról, hogy mi történt vele? Tudom volt benne 2-3 link, de úgy érzem a témába vágó hozzászólás volt.
   Kösz az infot,
7. idézem 2008.06.04. 04:55
   • Gábor
   @xsolutions Áttúrtam az adatbázist, de sehol sem találom azt a kommentet, pedig a spam-eket is eltárolom.
   
   Mivel tegnap és tegnapelőtt molyoltam a motoron, lehet, hogy a kommented egy leállított adatbázisba próbált bekerülni ezért elveszett, elnézést kérek.

Legutolsó hozzászólások

Végre IKEA!: Ági: Heló bárkinek, aki idetéved! A weboldalunk domain-je - a kedvenc áruházunk ügyvédjének nyumására :) - megváltozott: Az új cím: is...

DJ PLAYER Blue Edition: Gábor: Ja, és természetesen megy iPad-en is, hiszen _minden_ iOS app megy iPad-en.

DJ PLAYER Blue Edition: Gábor: Bug report-okat itt fogadunk: http://djplayer.net/page/bug_report_fixes

DJ PLAYER Blue Edition: hohand: Hello!A dj player mukodik iPad-on is?Tegnap feltettem, wifi-n athuztam ra zeneket,de amikor ranyomtam egy zeneszamra,error-t dobott es valami is!...

Uzsidoboz LED!: zo via Google Reader: vicces dolog, csak nem értem mire való