Stack Overflow - mi kell 200+ millió HTTP kérés kiszolgálásához

Címkék

Nick Craver elég részletesen bemutatja mi kell egy olyan weboldal kiszolgáláshoz ami naponta több mint 200 millió kérést kap.

Hozzászólások

Az elso komoly setup, ahol microsoft cuccokat latok. :) Szimpatikus az egesz.

Tényleg impozáns.
Szerintem a legtöbb magyar nagy (giga) szolgáltatónál tized ekkora sincs az összeállítás. Ami meg is látszik sokszor az oldalak betöltésén.
Ilyenformán erősen ajánlom tanulmányozásra a "tisztelt" szolgáltatók/bankok/ésatöbbiek rendszergazdáinak.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Igazából nem lepődnék meg, ha valójában sokkal nagyobb is lenne a géppark sokszor, csak mondjuk szimplán
a) komplexebb dolgok is történnek a háttérben egy stackoverflownál,
b) és még szarul is van megírva,
c) nincs ilyen szinten karbantartva
d) nem a megfelelő komponensekkel a megfelelő helyen.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szamomra epp azert impressziv ez a felallas, mert nagyon keves hardvernek tunik ahhoz kepest, amekkora szolgaltatast futtat. A masik cikkukben irjak, hogy az MSSQL-t futtato hardvereik CPU kihasznaltsaga olyan 10% korul mozog.

----------------------
while (!sleep) sheep++;

Na igen, de nem is egy tárolt eljárásokkal, triggerekkel teletűzdelt ERP-t futtatnak, ahol minden a DB-n fut. (Látok ilyet, na, ott nem 10% a CPU :)

Egy másik cikkükben kifejtik, hogy lehetőség szerint az FE-ken cachelnek, utána reddis, aztán a DB jön. Ugyanezzel szembesültünk mi is a saját webünkön: gyakorlatilag érdektelen az, hogy milyen a PHP kód, a terhelés 90+%-a a PostgreSQL-re esik mögötte. Ha lehetne rendes webalkalmazásként futtatni a szoftverünket akkor egy halom mindent becachelnénk mi is a frontendeken és mondjuk PostgreSQL-es notificationokkal frissítenénk az adatokat. (Ezzel amúgy valószínűleg a DB terhelésünk 80%-át meg tudnánk szüntetni saccra 50-100%-os FE terhelés növekedéssel. De most már senki nem fogja emiatt átírni ASP.NET-re vagy Java-ra az oldalt.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igen, könnyen elképzelhető, hogy egyszer meg is lépjük ezt Java-val vagy .NET-tel, de eddig nem akartuk bevállalni az ezzel járó plusz szopást, másrészt van hasonlóban tapasztalat (a rendszer keretrendszere egy egyedi fejlesztés, aminek készült egy igen jelentősen átdolgozott verziója a projekt indulása -2008- után, ami már backportolva lett és hát khm. néhol azért nagyon nem lett szép az eredmény a felszín alatt. (Persze, hosszú távra nézve maximálisan megérte, az új keretrendszerben egy csomó minden egyszerűbb, gyorsabban kivitelezhetőbb volt. Vagy eleve: volt. Csak a backport megtörtént olyan 2011-12 környékén és még mindig van jócskán olyan rész, ami a régi keretrendszer dolgait használja :)

Harmadrészt, nem ez volt a prioritás.

Negyedrészt, aminél ki tudnánk ezt használni, ott nem igazán volt olyan drasztikus módosítás az elmúlt években, aminél megérte volna, vagy gyorsabban kellett, hogy egy ilyen projekt beleférjen a keretbe.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A legtöbbször pont a rendszergazda az, aki nem tehet arról, hogy milyen infrastruktúrán kell szolgáltatni. És nem csak hardver, hanem szoftver oldalról is képesek ordenáré baromságokat csinálni... Kedvencem egy olyan appszerver+Oracle felállás, ahol az alkalmasint gyorsan cserélendő statikus tartalmat (kép, css, js) az Oracle-ből veszi a kiszolgálást közvetlenül végző appszerver - de úgy, hogy ezek valójában egy, az Oracle által valamilyen táblaként látott fájlrendszerbeli könyvtárban vannak...

Látom az utolsó mondatomra ugrott a hup közössége.
Kifejtve: Most nagyon sok kollégát megfogok bántani, de szerintem aki ilyen szinten nem képes az (önön)érdekeit képviselni, az menjen el utcaseprőnek.
Ebben a szakmában túlnyomó részt nem azért dolgozik az ember, hogy organikus robot legyen. Igenis meg kell mondani, hogy mivel lehet jól és gyorsan dolgozni. Leírva előnyöket, hátrányokat. Aztán ha rosszul döntenek odafönt, lehet lobogtatni a feljegyzést, hogy én megmondtam.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Lobogtatni lehet, meg ha olyan papírra nyomtattad, akkor másra is használhatod. És ez egyébként nem csak banki informatikára jellemző - ahol picit nagyobb számok röpködnek, ott nem az üzemeltetőknél van a döntés. Javaslatot jó esetben tehetnek, de bizonyos méret fölött a beszerzés technikai/technológiai _és_ üzletpolitikai döntés is.

> Ha az uzemeltetok egy ezreleknel nagyobb hatassal lehetnenek a donteshozatalra, nem itt tartana az ipar, hanem valoban 21. szazad lenne mar.

Vagy nem, ez két élű penge. Az üzemeltetőnek (helyesebben kb. mindenkinek, aki közvetlenül technológiai voanlon dolgozik) van egy preferenciája, amit (tisztelet a kivételnek) papagájként ismételget _bármilyen_ kérdésben. Az Oracle DBA sosem fog MSSQL-t javasolni. Az IIS-es szerverek üzemeltetője sosem fog nginx-et javasolni. A .NET fejlesztőnek eszébe nem jutna, hogy egy új projekthez Pythont javaosljon. Stb.

Miért nem tesznek az üzemeltetők a közvetlenül érintett dolgozók ésszerű javaslatokat (megint csak, tisztelet a kivételnek)? Kettő oka van:
1) személyes preferencia
2) kontroll elvesztése (t.i. ha egy projekthez X technológiát használnak, akkor az Y-hoz értő munkatársak veszítenek a mozgásterükből)

A technikai döntéshozói réteg azért létezik, hogy bizonyos inputok alapján hozzon egy döntést, amit utána keresztül lehet vinni a szervezeten.

Ez 2300 req/sec? Nem tűnik soknak...ja hogy ez nem ping vagy ARP csomag? :)

Komoly, irigylésre méltó összeállítás. Tetszik, hogy csak a cache (Redis) 240GB SSD, 256GB ram :)

2300req/sec esetén nekem kényelmes túltervezésnek tűnik.
Erősen hullámzó látogatottság mellett mi addig reszeltük a rendszer, amíg két, ehhez képest gyenge fizikai vason élő virtuális szerverek is elvittek ennyit csúcsidőben. Igaz az MS több gyorsjavítást is kiadott csak a mi igényeikre szabva, hogy bírja az IIS a terhelést...