A sun.com infrastruktúrája belülről

 ( trey | 2009. augusztus 12., szerda - 17:34 )

A műszaki embert mindig az érdekli a legjobban, hogy valami mitől és hogyan működik. Jed Michnowicz és Meena Vyas írásából kiderül, "hogy néz ki és hogyan működik a Sun publikus webszolgáltatás rendszere (www.sun.com, www.java.com, 6 regionális webszerver, összesen 50 website), hogyan van paraméterezve a Sun Web Server, milyen webszerver trükköket használnak. A rendszer napi kb 10 millió hit-et szolgál ki, összesen 12 darab szerverrel (ebből 6 db T1000 frontend a statikus és jsp alapú tartalmak kiszolgálására, és 6 darab X4150 backend)."

További részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

T1000, LOL. A www.intel.com meg 386-osokon fut. :)

Azt hittem valami komolyabb rendszert használnak, mondjuk földrajzi redundanciával, esetleg kontinensek közötti elosztással, hogy jobb legyen az ügyfélélmény.

Ja, nem, ez utóbbiakat visszavonom, hiszen akkor gyors(abb) lenne, amit már biztosan észrevettem volna.

ui: nem gondolom, hogy ez csak a Sunra jellemző...


suckIT szopás minden nap! Parsing made fun

Ne hülyéskedj már, folyékony fém :P

"Posted at 09:06AM May 31, 2006 "

Csak én nem látom a szmájlit a kommentedben? :)

Basszus, már négy éves ez a vas? Hogy repül az idő (itt, ott nem).


suckIT szopás minden nap! Tanítsd nagyanyádat!

Az alkalmazás szerverek 4150-ek.
T1000 csak előtét a statikus contentnek. Arra meg bőven jó.
(mondjuk engem meglepett, hogy csak ilyen kevés a szerver, de nyilván ha más nem, ők tudják hogy lehet agyontuningolni őket.)

Valaki Amerikából mérjen már egy 404 válaszidőt a www.sun.com-ra, meg a www.hp.com-ra. :)


suckIT szopás minden nap! Tanítsd nagyanyádat!

Nem mondom, hogy ez egy komoly meres, de tessek. A HP mindig kb. ketszer gyorsabb, tiz futas alapjan is....

csardi@geza:/tmp$ time wget www.sun.com/xxx
--16:31:40-- http://www.sun.com/xxx
=> `xxx'
Resolving www.sun.com... 72.5.124.61
Connecting to www.sun.com|72.5.124.61|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
16:31:41 ERROR 404: Not Found.

real 0m0.208s
user 0m0.000s
sys 0m0.000s
csardi@geza:/tmp$ time wget www.hp.com/xxx
--16:31:42-- http://www.hp.com/xxx
=> `xxx'
Resolving www.hp.com... 15.201.72.12, 15.201.72.13
Connecting to www.hp.com|15.201.72.12|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
16:31:42 ERROR 404: Not Found.

real 0m0.109s
user 0m0.000s
sys 0m0.000s
csardi@geza:/tmp$

vazz, nemá hogy 0.1 másodpercen rágjuk a gittet. :)

Nem tudom, hogy van -e osztva témánként, vagy minden részleget ugyanaz szolgál ki, de pl a partnel portálon néha érdemes elmenni két click között egy jó kávéra.... :)

A fentinek persze nem sok értelme van (főleg, hogy a wget futását is mérte a kollega :), mindenesetre rossz esetben pont ilyen 0,1 másodperces delayeket tesz rá a T1-es a kéréseid kiszolgálási idejére. Ha pedig letöltesz 20 képet, ráadásul nem is párhuzamosan, hanem sorosan...


suckIT szopás minden nap! Tanítsd nagyanyádat!

Ekkora eltérés nem mérvadó, főleg úgy, hogy nem ismert milyen hálózati szakaszokon mekkora a késleltetés az egyes esetekben.
Simán el tudom képzelni, hogy azért lasabb mert jóval hoszabb úton éri el, vagy van egy plusz műholdas vonalrész is.

Ettől független tény, hogy _innen nézve_ néha dög lassú a sun portál, de ezt okozhatja bármi más. (ok, sanszos, hogy az infrastruktúra, de nem egyértelmű)

mondjuk nem értem, hogy miért még a régi csoffadt T1000-ek vannak ott, mikor az újabb UltraSparc T2+ processzorok nem kicsit jobbak nála....

Azért US-ből US-be csak nincs műholdas kapcsolat, bár nagy ország, ki tudja. Egyébként:

traceroute to www.sun.com (72.5.124.61), 30 hops max, 40 byte packets
1 academic-gateway.knet.kzoo.edu (146.113.40.1) 0.671 ms 0.660 ms 0.928 ms
2 internal.knet.kzoo.edu (146.113.104.3) 1.582 ms 1.573 ms 1.883 ms
3 12.116.97.17 (12.116.97.17) 8.600 ms 8.594 ms 8.586 ms
4 cr81.dtrmi.ip.att.net (12.122.102.6) 66.788 ms 66.779 ms 66.772 ms
...

traceroute to www.hp.com (15.192.45.28), 30 hops max, 40 byte packets
1 academic-gateway.knet.kzoo.edu (146.113.40.1) 0.713 ms 0.702 ms 0.966 ms
2 internal.knet.kzoo.edu (146.113.104.3) 1.735 ms 1.729 ms 2.038 ms
3 12.116.97.17 (12.116.97.17) 8.719 ms 8.712 ms 8.704 ms
4 cr82.dtrmi.ip.att.net (12.122.102.66) 32.071 ms 32.065 ms 32.057 ms
...

"vagy van egy plusz műholdas vonalrész is."

Ebbe egy muholdas link kesleltetese nem igazan ferne bele (geostac muholdat feltetelezve).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

:) Na jó, de a wget az ugye minden esetben kb. ugyanannyi. Lefuttattam vagy tízszer, amit bemásoltam az egy reprezentatív futás. Saccra. :)

szamolj abszolut meg relativ hibat is :p

--
When in doubt, use brute force.

Akar a görcs 404-et benchmarkolni. :)
Az lenne a jó, ha nem is lenne. :)
Egyébként meg igen, néha (álltalában) idegesítően lassú.
De még ha ez lenne a legnagyobb baja... :)

Gratulálok. Szerinted a kettő ugyanakkora ügyfélbázis kiszolgálására épült? Gondolom neked is Sun márkájú nyomtatód meg fényképezőgéped van otthon.

LOL

Minden csak pénz kérdése.

Tehát, ha egy cég kevesebb embernek szolgátat, akkor megengedhető, hogy lassabb legyen a válaszidő? Ezt komolyan gondolod?

Minden csak pénz kérdése.

Szóval a Sun akkora sz@rban van, hogy arra sincs pénze, hogy azt a kevés pontenciális ügyfelet kiszolgálja? Vagy mit akarsz mondani?

Lassabb, mint...?

Szerintem a 200 ms válaszidő nem lassú. Lassabb, mint a hp.com, de a hp.com is lassabb, mint az amazon.com Akkor a HP is szarban van?

Eleg meglepo ez az architechtura. Marmint jomagam is azt hittem valami egesz komoly rendszeruk lehet.

De ez az fw>lb>dynamic|static kb a klasszikus "semmi trukk" felallas.

Amugy nemertem miert ne lenne a t1000 eleg statikus tartalom kiszolgalasara. akar 1db mind az 1200/sec re ;) Egy lighttpd talan nem, de egy cherokee vagy egy nginx siman kitolja 1db t1000tol azt a csucsidoben 1200 hit/sec -et. Bar arra nem emlekszem, hogy ez mondjuk most 1 oldal letoltes vagy 1 egyszeru hit a webserverre. Ha csak hit akkor ez a forgalom meglepoen alacsony, ha oldal letoltes akkor az egy ilyen sun.com eseteben a maga kozel 50 elemevel a frontpage-en nem lehet kifejezetten keves. Ellenben a sun.com messze nem olyan dinamikus mint egy hiroldal mondjuk. Rohogve lehet az egeszet cache-elni es kiszolgalhatod amirol csak akarod. Folleg ha hasznalasz egy akamai cdn backendet, mondjuk csak 30 perces ttl -el cache-elsz mindent es maris semmi para. Na mindegy nem bonyolult architechtura es a leirasban sem lattam semmi olyant ami kicsit is rendkivuli lenne szoval meglepoen semmitmondo az egesz. Hasonloan latogatott site-ot uzemeltetek most is es a webkiszolgalas a legkisebb problema.

drk

Nem vagyok benne biztos, hogy az nginx-féle kevés async, eseményvezérelt processz megoldás adja a legjobb teljesítményt ezen a vason...


suckIT szopás minden nap! Képrejtvény

> Nem vagyok benne biztos, hogy az nginx-féle [...] megoldás adja a legjobb teljesítményt ezen a vason

Szerinted mit lenne érdemes elsőként kipróbálni az nginx helyett?

"Ellenben a sun.com messze nem olyan dinamikus mint egy hiroldal mondjuk"

Nem értek egyet.
Minden nagyobb gyártó cég portál rendszere több részből áll, igen összetett.
Ha csak a termékek között mászkálsz, az tényleg statikusnak tűnhet, de nem az.
Ezeken a portálokon jelennek meg hírek elég rendesen, vannak különféle fórum részek, van jelentős méretű kereshető dokumentum archívum, kereshető tudásbázis, a partneri részeken mindenféle konfigurátor, stb....