Quickbench S02E01: Milyen lehet egy 128 processzoros AMD K6-os gép, avagy: sok lúd disznót győz?

Vélemény

A nagy(?) sikerű quickbench sorozat a világgazdasági válság ellenére is folytatódik a HUP-on! A lendület töretlen! Will work for food! Ezúttal -Márton nap elmúltával- azt a közmondást vizsgáljuk meg, mely szerint sok lúd disznót győz. De vajon tényleg?

( denes | 2008. 11. 17., h – 20:57 )

jol latom, hogy a sparc ketszer annyiba kerul ugyanannyit fogyaszt es fele olyan gyors mint a xeon-os cucc?

bocs a flamebait-ert :)

- Use the Source Luke ! -

< nemszeretemasunt_félretesz >
Ezek tényleg nem olcsók, de szerintem megvan a helyük, csak meglehetősen okosan kell azt megválasztani (és szerintem -ezért van a vélemény rovatban- kisebb is az a hely, mint az x86-os szervereké).

Te értesz annyira a dolgokhoz, hogy ha utánanézel, rájössz, hogy miben lehet sokkal jobb a mostani xeonos kínálatnál ez a vas (pontosabban a T2-re épülő vasak).

Úgy gondolom, hogy ez a szerver tényleg a szakembereknek szól, akik a megfelelő helyre megfelelő eszközt választanak. Na ilyenből persze kevés van, és ahol eddig ilyet láttam, mind rossz helyen volt (persze ez is IMHO).
< /nemszeretemasunt_félretesz >

Te értesz annyira a dolgokhoz, hogy ha utánanézel, rájössz, hogy miben lehet sokkal jobb a mostani xeonos kínálatnál ez a vas (pontosabban a T2-re épülő vasak).

kosz a bizalmat :) nem szertnem lerombolni a rolam alkotott kepedet, de mire gondolsz?
azt latom a tesztben, hogy nagy a memoria savszelesseg, de ezt csak specialis esetekben lehet apropenzre valtani - pl. ilyen esetekben valoban jobb valasztas lehet a sparc server.
de az osszkepet tekintve a helyzet - szerintem - nem tunik tul rozsasnak a sun szempontjabol.

amugy kosz a tanulsagos - es kimerito - tesztet!

u.i.: egyebkent nekem nincs bajom a sun-nal, a sparc is szimpatikus architektura volna - ellenerzeseim a sun sparc procikkal szemben onnan datalodnak, amikor megtapasztaltam a meregdraga sparc workstationok nem tul bika kepessegeit (bizonyos szempontbol intel celeron/amd sempron alatti szinvonal, az ultra 45 is). mondjuk ilyen kis szerias procikkal szerintem nehez csodat tenni (pl. ar/teljesitmeny tekinteteben), es nem is nagyon sikerul.

- Use the Source Luke ! -

pl egy jo alkalmazasi terulet kis kihasznaltsagu unix szerverek konszolidacioja. rengeteg olyan vas van meg szerte a vilagban. A vmware arat x86 piacon, de azon tulmenoen, hogy bonyolultabb ra mondjuk sparc szervert migralni (ha egyaltalan), meg mindig van egy olyan problemaja, hogy rosszul viseli, ha nagy szamu de kis kihasznaltsagu virtualis gep fut. Ujabb pl paravirtualizalt kernelekkel ez valamelyest kevesbe problema, na de az is inkabb csak linux. Es meg mindig nem nyujt a zonakhoz hasonlo kozos adminisztraciot, sot bonyolultabb bevezetni.

tovabbi erdekes alkalmazasi teruletek pl. mindenfele ssl gyorsitas, halozati dolgok (efele mutatnak az integralt 10gbps linkek es a memoria savszelesseg), internetes infrastruktura, akar alkalmazas kiszolgalas is, ha a valaszido nem annyira kritikus, vagy olyan az alkalmazas.

ez egy sun tervezesu gep, sun processzorral, mar hogyne lenne rozsas a helyzet, tiszta haszon. sokkal nagyobb uzlet nekik a coolthreads jelenleg, mint az x86 piac. az ar/teljesitmenyre meg akkor terjunk vissza, ha kapsz egy quote-ot egy konkret infrastrukturara. (az kevesbe szamit, hogy a cedulan milyen listaar van.)

a volume meg amugy se szamit. kulonben mindenki csak fogyasztas meg ar alapjan venne (kis) autot.

mindenesetre 100% egyetertunk az ultrasparc II/III tapasztalataiddal, nem vitatkozom, csak megprobalom mas szempontbol megvilagitani, mi ertelme lehet ennek a gepnek.

Mico írt dolgokat, ebből én az LDom-ot emelném ki. Vannak olyan helyek, ahol a biztonság számít, és az, hogy ebben a gépben 128 ilyen független domaint (igaz, ilyenkor meglehetősen csekélyke teljesítmény jut egyre) lehet kialakítani, komoly érv lehet.

Nekem a legnagyobb bajom az egyes szálak teljesítményével, és az általuk okozott erőteljes késleltetéssel van. A CPU kiválóan alkalmas hálózati feladatok elvégzésére (akár pld. tűzfalnak, terheléselosztónak), de csak akkor, ha a throughput, és nem a latency számít.
Olyan hálózatokban pld. ahol eleve magas késleltetések vannak (pld. rádiós, mobilhálózatok) lehet, hogy jól alkalmazhatók.

Sajnos a SPARC-okkal nekem is ez a problémám: hiába lennének jók, drágák, és teljesítményben péppé verik az x86-os dobozok, és ez a nagy gépeknél is csak azért kevésbé igaz, mert nincs pld. 64 CPU-s opteronos doboz. :-O

Ami még megmozgatná a fantáziámat az a crypto offload, és esetleg egy olyan, specializált kernel, amely (akár saját LDom-okban futva) célfeladatokat lenne képes ellátni, anélkül, hogy egy általános OS nyűgjeit magával kelljen vinnie,
amolyan koprocesszorként funkcionálva.

Ilyeneket az Opteronok (HT) kapcsán is vártam, talán volt is egy-kettő, de sajnos eléggé kicsi a piac ahhoz, hogy általánosan elterjedjen.

Érdekes kérdés még, hogy az erősen párhuzamos, például funkcionális/párhuzamos nyelvekben írt alkalmazások hogyan lennének képesek működni.
Ezekben talán nagyobb potenciál van, mert könnyebben lehet velük sok magra skálázódni, elhagyható a többszálú, osztott erőforrásokat használó alkalmazások lockolása (ami ezen a CPU-n különönsen kritikus, mert egy-egy szál sokkal lassabban fut, ergo a lockot is tovább tartja, mint egy pécén), és talán a feladatok "szétszórása" is kisebb egységekben lehetséges és értelmes, mint másban.

Nagyjából egyetértek veled. A Sun túlságosan elrugaszkodik néha a marketingjében, hogy mire képesek ezek a vasak. Néhány gondolatom azért mégiscsak van a méréseiddel kapcsolatban:

A sun4v architektúra tényleg nagyon jó az adat be + adat ki feladatokra. És tényleg nagyon rossz az utasításfeldolgozója. Az adat be és az adat ki között minél több utasítást kell végrehajtania a procinak, az annál nagyobb halál neki. Ezt a nyers benchmarkok is bizonyították. Ezzel kapcsolatban például lehet javítani a teljesítményen megfelelően fordított programokkal - például a fordító megválasztása is lényeges ilyenkor (gcc vagy studio). Abban viszont biztos vagyok, hogy ez legfeljebb 5-20% teljesítménynövekedést adhat csak, nem elegendőt arra, hogy trófeát vigyen a vas.

A másik dolog pedig, amire te is rávilágitottál, hogy mennyire skálázódnak az alkalmazások. A példádban pont a ZFS ZIL-je jött ki szűk keresztmetszetnek, de szerintem megérnének egy-egy analízist a bind és postfix mérések is. Igen, az első két mérésnél hiányolom azt, hogy kerested volna a különbség okát.

Köszönet a mérésekért. Mennyi időt töltöttetek ezzel?

Tanultam méréstechnikát, az alapján nem hívnám ezeket méréseknek. :)
Ennyire volt időm/energiám.

A külön fordított programokat ezzel készítettem, legjobb tudomásom szerint ez nem gcc :) :
gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /net/clpt-v490-1/export/data/bldmstr/20070711_mars_gcc/src/configure --prefix=/usr/sfw --enable-shared --with-system-zlib --enable-checking=release --disable-libmudflap --enable-languages=c,c++ --enable-version-specific-runtime-libs --with-cpu=v9 --with-ld=/usr/ccs/bin/ld --without-gnu-ld
Thread model: posix
gcc version 4.0.4 (gccfss)

A postfix esetében nem hiszem, hogy az alkalmazásban olyan jellegű szűk keresztmetszet lett volna, mint a bindban. Nyilván engem is boldogabbá tett volna, ha legmélyebb bitszintig lemehettem volna, részletes bugreportokat, sőt diffeket küldve a fejlesztőknek, de sajnos ehhez sok helyen tanulnom is kellett volna nem keveset (nem fújom például sem a postfix, sem a bind forrását, a kritikus részeket minimum meg kellett volna értenem), ez pedig sajnos felesleges munka lett volna, mivel nem tervezek ilyen gépeken ilyen alkalmazásokat futtatni. :)

2-3 hét volt (nagy része nyáron, szabadság helyett :) kb.

A messaging server esetében egy-egy teljes teszt kb. 4-5 napig futott, ezt szorozni kell két géppel, és minimum három szcenárióval (ZFS, ZVOL+UFS, ZIL disabled), plusz a hibakereséssel, script-fejlesztéssel, hasonlókkal.

Igazán írhatna már valaki olyan elosztott teszt alkalmazást, amelynél csak meg kell nyomni a gombot, és a végén szép grafikonokat gyárt (például ezzel is szívesen tölteném az időmet, de vannak sokkal fontosabb dolgaim is).

Amit linkeltem, az sem gccc :D

Teljesen megértem az erőforáshiányt a "miértek" keresésére, de egy prstat azért gyorsan elárulta volna, hogy ott is postfixet futtat-e a számítógép, vagy mutex/spin lockot...

És ha jól emlékszem, Wietse Wenema nem szokta szeretni, ha neki patch-eket küldenek, úgyhogy jobban is tetted, hogy megkímélted :)

Igazán írhatna már valaki olyan elosztott teszt alkalmazást, amelynél csak meg kell nyomni a gombot, és a végén szép grafikonokat gyárt

talan nem vigasztal, de hogy az elmult 2 ev munkaidom 10% -at teljestimenyteszttel vegeztem, es meg az utolsonal is scriptreszeles, tesztprogram beloves, forditas, gnuplot varazslasok, ateljes tesztelesi idonek majd a feleben :-)

A zfs+zil rosszul skalazodik dolog kicsit meglepett (nincs zfs tapasztalatom) de nagyon nem: tobb diszkes mukodest vagy nvram journalinggal (hw raid) oldanak meg, vagy bevallalva a nagyobb kockazatot (eldobjak a barriert, szerencsetlen aramszunetben serulhet az fs journal). Hatarozottan erdemes lenne kiprobalni nvram -mal felszerelt HW raiddel. Varhatoan ugyanazt kapnad, mint amit ZIL nelkuli esetekben mertel: nem fugg a procitol es az architecturatol nagyon, csak a diszktol fugg lenyegeben a teljesitmeny. (ami nem megpelo egy io intenziv alkalmazasnal).

Nagyon koszonom a cikket, jo erzes volt elolvasni (es tudni, hogy mas is beleoli a munkaorak szazait, csak azert, hogy sajat velemenye legyen:-).

Külön szakma ez...

Mondjuk ha tényleg ez lenne a munkám, már biztos írtam volna valamelyik keretrendszerhez (pld. slamd, vagy tsung) egy rakás tesztet, nem pedig ilyen alkalmi scriptekkel nyomulnék.

Főleg a több gép szinkronitása, figyelése és az eredmények összesítése a problémás, a fentiekhez hasonlók ebben azért sokat tudnak segíteni...

Alapvetően igazad van. Hadd legyek közhelyes: programozó ideje kontra gép ideje.

A széles fejlesztőtömegek számára az fontos, hogy legyen egy (több) megbízható, hatékony és biztonságos fejlesztést támogató, automatikusan párhuzamosodó / eloszló eszköz, még azon az áron is, hogy az egyes csomópontok (mag vagy gép) erejének mondjuk kétharmada elmegy a futtató környezetre.

Szükség lesz azonban (bár biztosan lényegesen kisebb súllyal) olyan alkalmazásokra is, ahol a fenti arány (más szóval (nem-pejoratívan értett!) "megalkuvás") nem fogadható el. Bár egy időben én is lelkesen kontárkodtam a Haskell-lel (még a monádokat is értegettem, úgy-ahogy, bár úgy látom, ezen mindenképpen érdemes lesz még átrágnom magam), azért a hobbim a C-hegesztés, ezért volt az előző példám ilyen irányban elfogult. Ismétlem, természetesen igazad van, hogy általánosságában távolodni akarunk az explicit párhuzamosság-kódolástól, illetve ha muszáj azon belül maradnunk, akkor inkább az üzenetküldözgetés felé tendálunk.

A proggit-on egyébként mindennapos a flamewar a témában. Lásd például (és ez egy gyenge példa): Multicore parallel death match! Parallel Haskell, `par`, and C.

Gyorsan kerestem is a témák között egy kicsit, hátha találok Számodra néhány linket, amely (magától értetődően) sokkal frappánsabban és részletesebben leírja, amit fent elbanalizáltam:

Making the transition from sequential to implicit parallel programming: Part 6 -- So, why aren't we using functional languages yet?

Making the transition from sequential to implicit parallel programming: Part 8 -- Turning parallel Haskell (pH) into a production language

Embedded software stuck at C -- No parallel languages for multi-core on horizon

Interviewing the Parallel Programming Idols

(Ezért is írok hajnali ötkor...)

Tegyük hozzá, az adok-kapok nemcsak a mezei programozók fórumain folyik az imperatív ill. funkcionális (deklaratív) hívők között, hanem a nagyok csatornáin is. Nyilván sokkal kifinomultabb eszközökkel, de azért vegyük észre, hogy amikor arról írnak részletes cikket, hogy hogyan készíthetünk lock-mentes adatszerkezeteket C-ben, amelynek még specifikált memóriamodellje sincs, és hogy minden processzor-architektúra ill. fordító máshogy rendezi át az utasításaidat és másféle barrier-eket igényel(ne), meg hogy milyen megfontolásokkal érdemes spinlock-ot használni súlyos mutex helyett, akkor nem biztos, hogy jó irányba sugallmazzák a széles néptömegeket. (Persze aki ilyen cikket ír, az általában hozzáteszi a végén, hogy "tudod mit, inkább felejtsd ezt el, és zárolj inkább".) Példák (szerintem érdemes mindegyikbe legalább belekukkantani):

The "Double-Checked Locking is Broken" Declaration

Writing Lock-Free Code: A Corrected Queue -- Think in transactions, know who owns what, and use ordered atomic variables

Multicores and Publication Safety

Who ordered memory fences on an x86?

Who ordered sequential consistency?

The JSR-133 Cookbook for Compiler Writers

( Mico v | 2008. 11. 17., h – 21:01 )

azt azert nem gondoltam hogy _ennyire_ elmelyulsz benne
_azota_ ezt csinalod? :)

btw mivel ez itt a reklam helye.. a management kepessegek az osszes sun szerverben benne vannak.. lehet venni inteleset is akinek budos a sparc :)

Éveket el lehet szórakozni ilyenekkel, főleg, ha tudományos pontossággal (ami teljesen hiányzik a fentiekből) akarja csinálni az ember.
Itt éppencsak ránéztem, sajnos dolgozni is kellett mellette.

Amúgy nem, csak most volt időm összegezni az eredményeket.

Ez a mostani szerver-széria viszont tényleg jónak tűnik (akár x86-os, akár SPARC-os).

Annyira nem is követtem most ezeket a dolgokat (meg mielőtt megjelennek, úgyis szokott valaki demót küldeni, az egész jó indikátora annak, hogy hamarosan piacra kerül :), de ezt megnézve:
http://en.wikipedia.org/wiki/Nehalem_(microarchitecture)

van egy 2009. Q1 (Gainestown), és 2009. Q4 (Westmere).

Utóbbi tényleg elég messze van még, na de az előbbi (már persze ha meg is jelenik)?

azt mondtak, hogy a shanghai-hoz kepest legalabb 6 honap lesz, mire a szerver nehalem erkezik, 2009q4 (a 4+ procis) meg eleve jo messze van. az amd architekturaja mar kesz van, feltelezhetoen nem kell most se sokat varni a 8000-es sorozatra. meglatjuk, mit tud ebbol az elonybol az AMD kihozni.

mindezt az amd egyik embere mondta amerikaban, lehet hogy nemigaz, de nem zacskobol akart ranksozni procit gyorsba, szoval miert hazudott volna. kerdezem, a roadmap-hez kepest is kesik, igen ahhoz kepest.

Nagyon drukkolok az AMD-nek, bár végső soron nekem, mint végfelhasználónak csak az a lényeg, hogy olcsón, gyorsat és emellett lehetőleg hatékonyan működő eszközt kapjak.
De ezt egy szereplő nem tudja megadni, kell hozzá a verseny, abban pedig jelenleg csak az Intel és az AMD vesz részt, a Sun SPARC-os megoldásai teljesen másra valók...

( zeller | 2008. 11. 17., h – 21:53 )

Az "IOIOI" :) 9 tűs papa nem lehet, hogy hagyományos soros csatlakozó?

Szerintem az a sikitoszellem cetlije. Azt jelzi, hogy holnapig be fog dogleni a gep.

(Ha jol emlekszem, korabban eppen bra irt egy hasonlo beszamolot egy geprol, Pratchett par elemet kolcsonveve. Szoval erteni fogja. :) )

--
I don't always dress in a T-shirt and jeans. Sometimes people give me awards, and I dress like a penguin instead. - Linus Torvalds

( biboka v | 2008. 11. 17., h – 22:55 )

Háth, ilyen cuccokkal én is eljátszanék egy keveset...:-) Asszem ez nekem egy ideig a "beteljesedetlen" kategória marad:-/

Spec. alapján már rég kiszúrtam a T2-t, nagyon jónak néz ki így a tesztek alapján is. A leírás meg tök jó stílusúra sikeredett, gratula hozzá!

( vomberg | 2008. 11. 18., k – 01:51 )

és egy rejtélyes "IOIOI" feliratú, ismeretlen rendeltetésű konnektort, amely olyan furcsán eltér a többitől:

Embeeeer...!

Az az RS232 csatlakozó!:-))))

A screenshot-on is láthatod, hogy Serial console started. To stop, type #.

Jelzem, a HP/Compaq desktop gépeken jelölik így rendszeresen.

Ha mar embeer, annak a csatlakozonak egyebkent sincs semmi koze a serial konzolhoz. Az a LOM uzenete, amit manapsag leginkabb pl. SSH-n ersz el, de lehet a Serial mgmt feliratu aljzaton is (RJ45). A (mostar tenyleg) ismeretlen rendeltetesu csatlakozo a hagyomanyos ertelemben vett "COM1" a host fele..vagy ahogy beallitod

( dikki | 2008. 11. 18., k – 19:27 )

En egy x4500ast nyuzok... bevallom, meg telepiteni se sikerult. A 48 diszkbol ketto bootolhato, a /dev/sdac -ra sikerult grubot tenni de nem arrol bootol, a /dev/sdy -ra nem sikerul - szerintem arrol akar....

Kb fel oraja van, aztan feladtam.

Majdnem 15 év tapasztalata beszél belőlem. :)

A sok diszkes felállásból egyik kedves emlékem, amikor a "linuxos" kollega próbálta meg elindítani szeretett Debianját egy olyan gépen, amelyiken több -pontosan már nem emlékszem, de biztosan 16 felett- LUN volt, és már a LILO képtelen volt működni, aztán pedig miután azon túltettük magunkat, a driver forrásában kellett egy konstanst átírni, mert 16-nál több eszközt amúgy nem tudott kezelni.

Akkor te jobban jartal LILO-val, mint en. Anno teljes "rendszer" telepites utan jo izuen hatradolve bootoltuk ujra a gepet n+1. alkalommal, tesztelven, h minden rendben van. Ez a tragya ugy dontott, h o most megsertodik es nem mukodik tovabb. Mint egy maszuletett kiskacsa LI LO LI-zta tele a monitort. Pedig csak egy disk volt benne. Az volt az utolso alkalom, h kiejtettem a nevet a szamon, es a pokolba szamuztuk. A Debiannal egyutt. :)

---
pontscho / fresh!mindworkz

Kb. 2000 óta saját gépen ilyet nem láttam, "élményeim" csak azelőttről vannak.
A tiédhez hasonlók, upgrade után végtelen ciklusban print, működésképtelenség, szopás a diszkgeometriával, stb.

Ritka szar egy valami. PC-n a boot az egyik legfájdalmasabb dolog, szerencsére mára már csak a Solaris (és a GRUB) kínlódásait kell néhe végignézni (dupla élvezet, a Solaris PC-n ugyanez a kategória), a többi gépnél a FreeBSD úgysem diszkről bootol, ráadásul azzal sosem volt annyi gond, mint ezzel a többi hulladékkal. :)

Update: Csakazértis rákerestem hivatalos doksira ha már mindenáron linuxszal szeretnéd gyötörni az X4500-as hardvert:
The boot device nodes are /dev/sdy which is located at slot 0 and /dev/sdac, located at slot 1. The operating system must be installed on one of these device nodes.

Megnéztem, sőt láttam is tegnap, hogy ezekre tippeltél :)
Ha viszont így sem akarja, akkor az csak egyet jelent: látens Solaris-függő a gép :).
(Egyszer majdnem Debiant telepítettem egy Opteronos Sun vasra kínomban, mert Solarisszal összeakadt az arcszőrzetem, de végül rászántam az időt keresésre, és rájöttem, hogy felvarázsolni rá azt a Linuxot sokkal macerásabb, mint keresztbehackelve újratelepíteni Solarist. Amúgy ha írnak Linuxos támogatást, akkor nagy eséllyel tényleg mennie kell, legfeljebb nem lesz triviális (pl. külső hdd-ről telepítés stb.)).

( pasztorl | 2008. 11. 19., sze – 14:21 )

Bra: jó a teszt köszi, hogy közzé tetted.
T2: Tettünk vele egy próbát mi is real-life web kiszolgálásban (tomcat), az ellenfele DL140 (2x4core xeon 2.33Ghz) volt. A tapasztalat, hogy nagyságrendileg ugyanaz a teljesítmény jött ki a két gépből. Nyilván szoftver/jvm optimalizációval több is kijöhet a T2-ből, ha olyan kedvezmények lennének itthon az alapárára + üzemeltetésére mint Amerikában már átnyergeltünk volna erre a platformra.
X45xx: statikus kiszolgálásban az látszott, hogy a linux 16 diszkes raid5-ig gyorsabb volt mint a solaris+zfs kombó, viszont több diszkel már alul maradt. Ez legfőképp a linux md implementációjának köszönhető. Végül linux mellett döntöttünk 8 diszkes raid5 tömböket felhúzva (a szoftver oldalon úgy is megoldott már a loadbalancing)
Jelenleg 4 ilyen vasunk van, szeretjük:) Az operátorok már kevésbé, mert ugye a tetején kell belepakolni a diszkeket és ki kell húzni teljesen a rackből ahhoz, hogy az összes diszket elérjék...

A DL140 azért eléggé a legalja a rackmount PC-knek, a fenti gép közelről sem hasonlítható hozzá. :)
Jó tudni mindenesetre, hogy az (elvileg) egyik célterületen más is hasonló konklúzióra jutott.

Kedvezményeket egészen biztosan lehet szerezni, ez csak a "commitmenttől", a felhasználás és a vevő komolyságától, nagyságától függ...

Az IO teljesítményt mivel, milyen jellegű terheléssel (és milyen fájlrendszerrel a Linuxon) mérted?

DL140: itt igazából a processzor + ram sebesség számít nem az egyéb extra featurek amit egy high-end gép ad. Nyilván tudtuk volna versenyeztetni egy hasonló teljesítményű(cpu,ram) ámbár 2-3x ennyibe kerülő high-end csodával is.
Kedvezmények: amit itthon kapni lehet erre a gépre azt sztem megkaptuk;), mondjuk hozzá kell tenni, hogy a versenytárs is igyekezett...

X45xx: statikus webkiszolgálás 70k átlag fájlmérettel. A filerendszer ext3 (raid chunksize, ext3 stride,stripe paraméterek beállítva). A terhelést slamd adta előre összerakott random requestekből 80+ slamd klienssel 1gbites hálón.

Ami nekem leginkább bejött ebből a vasból, az az LDOM-ok.
Simán telepítettem rá Solaris 10-et, és ubuntu-t amik vidáman elfutotak egyszerre rajta. A Sol10-ben használható zónákkal kombinálva már a legperverzebb igényeket is kielégítő virtualizációt lehet vele csinálni. :)

( 54ny7 | 2008. 11. 19., sze – 21:27 )

itt Zircen annyira foglalkoznának vele?:)

( turul16 v | 2008. 11. 20., cs – 23:58 )

Apache ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mi van vele?
Statikus webkiszolgálásra preforkos és threades módban is elvileg hasonló eredményeknek kellene kijönniük, mint a postfixnél:
- ha keepalive van, gyorsabb
- ha sok kapcsolatfelépítés van, lassabb

Ha nagy fájlt kell kitolni (csak IO van, lapátolni kell az adatokat), jó a CPU, míg eljut odáig, az lassú.