Názory k článku Jak jsem instaloval a testoval FreeBSD 5.2 (2)
-
junix (neregistrovaný)
Jen bych jeste doplnil jeden dotaz na to vyladene jadro. FreeBSD 5.X jako vyvojova verze ma defaultne zapnuto spoustu debugovacich a ladicich funkci, ktere vyrazne ubiraji vykon. Vetsina techto funkci se da vypnout, kdyz se v konfiguraku kernelu zakomentuji nasledujici radky:
# Debugging for use in -current
#options DDB #Enable the kernel debugger
#options INVARIANTS #Enable calls of extra sanity checking
#options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS
#options WITNESS #Enable checks to detect deadlocks and cycles
#options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed
Pise se o tom v /usr/src/UPDATING.
Tak bych se chtel zeptat, jak to bylo ve vasem pripade. Nechci vypadat, jako dalsi fanaticky zastance, ale mozna by pro vetsi objektivitu bylo lepsi udelat ten test jeste i pro produkcni verzi 4.9. Ne ze bych cekal, ze bude vykonnejsi, nez Linux (on o vykonu leccos naznacuje ten serial o porovnavani obou systemu)... -
Michal Kára (neregistrovaný)
Vyse uvedene nastaveni bylo:
#options DDB #Enable the kernel debugger
#options INVARIANTS #Enable calls of extra sanity checking
options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS
#options WITNESS #Enable checks to detect deadlocks and cycles
#options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed
Takze jen INVARIANT_SUPPORT bylo zapnute. Mohu ho jeste zkusit vypnout, jestli myslite, ze to bude mit meritelny vliv. -
junix (neregistrovaný)
No, to uz asi vyrazny vliv mit nebude, tedy jestli spravne chapu vyznam, tak se tam sice nejake ty funkce pridaji, ale bez INVARIANTS se pak nevolaji.
Nicmene by bylo zajimave jeste udelat ten test s verzi 4.9, alespon pro uplne uspokojeni nas BSDckaru :). Mimochodem jadro FreeBSD 5.2 a 4.9 ve stejne konfiguraci se lisi velikosti vice jak o 1MB (vice nez 20%). Samozrejme to s vykonem nemusi primo souviset. -
Jerry III (neregistrovaný)
No co sme delali naposledy load test v praci tak Win2k Server na dual PIII Xeonech na 733MHz s 1GB pameti nam byl schopnej dodavat pres 1,200 dynamickejch stranek (Asp.Net dotazujici databazi), kazda nekolik desitek KB, a byl by schopnej pravdepodobne i vic, ale my sme nemeli dostatek klientu na testovani (jelo to ze ctyr a vsechny byly vytizeny na 80+%, coz docela zkresluje ty cisla). A jak uz tu bylo poznamenano, staticka 1.5KB stranka je o nicem... Az ten test pojedeme znovu (coz by melo byt relativne brzo) tak muzu pridat cisla s podstatne vic klientama, v tomhle je vylozene bottleneck klient, ne server.
-
dejf (neregistrovaný)
Jo, je to zajimave, ale test minuta/minuta je na houby. Rozdil mezi FBSD a Linuxem na pracovni stanici porovnavam tak, ze to necham jet s Xkama dokud to jde pouzivat a v tom je (asi) BSD lepsi. Linux po mesici az dvou zpomali protoze sezere skoro vsechnu pamet (vice dister, jadra od 2.2 do 2.6-test1) a nema cim cachovat, FreeBSD se na te same stanici do podobneho stavu jeste nedostalo, protoze zatim vzdy stihly drive vylitnout pojistky, kazdopadne spickovy uptime mam s 5.0 (! hodne unstable, ale nevim jak se to pozna, nic mi tam nespadlo) skoro pulrok.
Takze krom doplneni serverove zajimavejsiho OpenBSD, produkcniho FBSD 4.9, a pro zajimavost by stalo za to dat si Plan9 (prekvapil by asi skoro vsechny), bych jeste s tim vsim udelal test dlouhodoby, treba mesic trvaleho vytizeni. Vic nema asi smysl, protoze je treba kvuli bezpecnosti obcas vymenit jadro a navic nemam poneti, kdo by byl ochoten obetovat na mesic 4 nebo 5 slusnych pocitacu :( -
kciii (neregistrovaný)
- nikdy som nic poriadne netestoval, nepriek tomu ked pouzijem sedliacky rozum musia mi byt jasne urcite veci.
- problem s castym alokovanim rozne velkych blokov je znamy a je to skor chyba X-ov ako OS. Ked ale proces skonci a spusti sa znova tak pamet je zas volna. Teda server s tym problem nema lebo 1. nealokuje jak divy, 2. nie je nutne pouzivat donekonecna ten isty proces.
- o OpenBSD je zname ze vykonovo je daleko pozadu. -
Pichi (neregistrovaný)
No já mám appserver na kterém naráz pracuje 7 lidí (mají na tom komplet desktop environment Icewm+ROX) v paměťových žroutech GIMP, OpenOffice.org a Mozilla a spol. Honím to na poněkud obsolet 2.4.22-xfs přímo z Knoppixu (já vím, že jsem čuňátko a není to bezpečné). Všechno to jede pochopitelně nonstop (97 days, to byl výpadek elektriky delší než UPS snesla). Žádný memmory leak jsem nezaznamenal, tak se mrkněte co za sprasenou app (nebo X server? - ty jsou pochopitelně na terminálech {X86Free sux}) vám tu paměť vyžere a přestaňte FUDovat.
-
hyperion (neregistrovaný)
testovaci SLES8 (PIII 1Ghz, 640MB RAM) s Oracle9i + Oracle9iAS po 80ti dnech uptime vyuziva asi 250MB swapu (pripojuje se nekolik desitek useru). nemyslim si, ze by se vzrustajicim casem nejak radikalne chlemstal pamet nebo mel velkou zatez (a to je aplikacni server + java slusnej zrout..)
-
jam (neregistrovaný)
nerad bych byl opet osocen za nohsleda BSD, ale zajimalo by me jak by dopadla 4.9-RELEASE (zatim posledni verse 4kove rady.
precejen je 5.x zatim ve vyvoji a zle jazyky tvrdi, ze petkova rada je o rad pomalejsi nez ctyrkova a proto by me zajimalo co je na tom pravdy.
PS: nehledejte v tom prosim nejakou soutezivost a snahu o diskreditaci techto testu. proste me jen zajima jak dopadne 4.9 oproti 5.2, nikoliv oproti linuxu :) -
dip (neregistrovaný)
Jen bych tu rad v duchu znameho flame-throweroveho clanku biesdyckare neologisma pronesl nasledujici, diky:
- Cumis, vid, pico. Hlavne ze mas ten svuj skoroUNIX "cistej" a nejlepsi. Ok, sedni si za tu udejchanou chcanku a uzivej si ten free pocit treba pri preinstalovavani userlandu po zmene jadra. k00l OS, to FreeBSD. :-p
- Coze je tam jeste lepsi, aha, init. A to myslis vazne? Protoze kdokoliv trochu zbehlejsi si napise BSD-like init skripty pres odpoledne na kolene. Ty bys to mozna zvladnul taky, ale to bys nesmel mit v hlave nalitej kybl "hoven, co nahodou bezej vedle sebe".
Ahojky, lol. :) -
CrONiN (neregistrovaný)
Skuste to z optimalizovanou verziou 4.9. Btw, vacsi vplyv ako optimalizacia underlaying OS by mala mozno optimalizacia samotneho apaca (vid highperformance-std.conf subor a odkazovane manualy), alebo na testovanie nepouzit apache, ale nieco o niekolko radov jednoduchsie, t.j. menej konfigurovatelne, t.j. umoznujuce viacej vyniknut rozdielom medzi operacnymi systemami a ich nastaveniami, napr DjB-publicfile (http://cr.yp.to/publicfile.html).
Z optimalizacie davam do pozornosti volby (v naznacenom pouziti):
options ENABLE_VFS_IOOPT
#options UFS_DIRHASH
a samozrejme prepinac -03 pre gcc. -
Mikuláš Patočka (neregistrovaný)
Ochranu proti syn floodu má jak Linux tak FreeBSD. Ale nemyslím si, že by to na výsledky testu mělo vliv. Na linuxu se aktivace syncookies dá (asi) poznat z hlášky na konzoli, nevím, zda je to tak i u FreeBSD. Ale myslím, že na lokální síti k tomuto problému nedojde.
-
Marek Sezemsky (neregistrovaný)
nedavno jsem cetl o syncookies na Linuxu (dokonce myslim ze v clanku o srovnani FreeBSD a Linuxu) ze ochrana se zapina az se dosahne urciteho poctu pripojeni, tzn. ze neni aktivni od zacatku ale kdyz zacne tcp stacku 'dochazet dech'. Ale vzhledem k vysledkum to imho nehralo roli.
jak to funguje u FreeBSD nevim -
michal (neregistrovaný)
To je zajimavy, me to v Mozille (na Linuxu) nefungovalo ani z matfyzi laboratore, ani ted z domova - pise to forbidden. Ale "rucne" mi to ten soubor posle:
$ nc lemming.webpark.cz 80
GET /mykernel.txt HTTP/1.1
Host: lemming.webpark.cz
HTTP/1.1 200 OK
Date: Thu, 04 Mar 2004 09:13:00 GMT
Server: Apache/1.3.26 (Unix) PHP/3.0.18 mod_czech/3.1.0 mod_ssl/2.8.9 OpenSSL/0.9.6g
Connection: close
Transfer-Encoding: chunked
Content-Type: application/octet-stream
ff9
#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
atd.
Asi nejak divne vyladeny Apache :-) -
Martin Kuchař (neregistrovaný)
Tak to je zajimave. Mam na Win IE a Mozillu, resp. Firefox. V nem to opravdu krici Forbidden. Pak to zkusim IE a funguje to OK. Potom zas Mozillou a uz taky OK. Mam v ceste Squida, do ktereho to asi nacetl ten IE, proto Mozilal na druhy pokus fungovala. Proc to ale neproslo Mozillou poprve opravdu nechapu. Jeste jsem se s tim nesetkal !
-
CrONiN (neregistrovaný)
Nie, rozdielom nie je len cena, je to (najma ale nielen) vecou implementacie vnutornych pamati. Mepamatam si to presne, je to popisane (napr.) v knihe Micahela Lucasa "FreeBSD - sitovy os" a ide priblizne o to, ze pokial drahe karty z dobrou implementaciou vnutornych vyrovnavacich pamati zvladnu prave take narazy poziadaviek na spojenie, ako sa testuju v clanku, lacne karty tieto pamate nemaju a pri vyssej zatazi sa pakety (alebo este skor ramce) zacnu stracat, co si vynuti opakovanie paketov na urovni TCP, etc, cim sa dalej zvysi zataz, vznikne kladna spa:tna vazba a dosledky si kazdy domysli.
FreeBSD dokaze spolu s vyrovnavacimi pamatami v hw sietovych kariet dobre spolupracovat, ale karty bez tychto pamati sa vyslovene pre fbsd neodporucaju. Menovite Rlt8129/8139 su oznacene ako nevhodne cipy pre fbsd. Pamatam si to, lebo cistou nahodou mam na svojom desktope (pod fbsd) prave sietovku Rlt8139. Vyhodou tychto kariet je na druhej strane to, ze bezia snad aj na hriankovaci. :-) -
'Kockac' Mato K. (neregistrovaný)
3Com je strasny smejd, ktory by som bral tak za patinovu cenu 8139ny, ale nechajme to bokom...
8139 je naozaj dost malo vykonna, neda sa s nou dost dobre robit zero-copy a podobne. Podla mojich narychlo spravenych testov ma FreeBSDckovy komp s 8139 asi o 25-30% vyssiu zataz z preruseni ako rovnaky stroj s Intel EE100 (fxp driver - _bez_ nainstalovania vylepseneho mikrokodu - t.j. ifconfig fxpX -link0).
Na druhej strane pouzitie DEVICE_POLLING ma za nasledok zvysenie vykonu, ale hlavne znizenie zataze o niekolko radov. Aj pri 8139. Bez vyraznej stratovosti. -
MOJE (neregistrovaný)
to jo
je to mnohem lepsi, nez 8139
ale je to neco, jako rozdil mezi D/A prevodnikem na paralelni port a SB16. Je to mnohem lepsi, ale porad to jeste nemusi byt ono. Napriklad 3comy podle mych zkusenosti obtizne zvladaji fullduplex, takze kartou se mi podarilo protlacit v jednom okamziku "jen" 100mbit. A pritom by to melo jit 100 kazdym smerem. -
'Kockac' Mato K. (neregistrovaný)
Tvrdenie by som rozhodne nepodlozenym nenazval. Musim uznat, ze architektura 8139 nie je dobra, ale 98% tych kariet proste ide ako po masle. V pripade 3Com sa to povedat neda a zazil som situacie, kedy sa proste 3Coma musela vymenit za 8139, aby siet isla. Minimalne 5%. Nevravim o pripadoch, kedy to chodilo len obcas a podobne.
Asi vsak mas/te iba 3Com zariadenia (switche, routre etc.), v takom pripade to tvrdenie moze prist nepodlozene, pretoze prave v tej konfiguracii to ide takmer 100%ne. Ale _len_ v tej konfiguracii. Poviem len jedine: Takto si kartu, za ktoru mozem mat 4x 8139, rozhodne nepredstavujem.
A ze ma viac vlastnosti? To sa mam nad tym vytesovat, kym mi nejde server? -
Peto_MiG (neregistrovaný)
Zaujala ma debata okolo sietoviek. Chcel by som stavat server a neviem, aku sietovku tam dat. Zrejme bude mat chipset nforce2 a teda NIC nVIDIA onboard 100/1000, ale je to dostatocne vykonne rozhranie? Alebo sa radsej spolahnut na pridavnu sietovku? A ak, tak co by som mal volit medzi 100MBit 3com a 1000Mbit Realtek? Pre ziadnu 1000Mbit 3com som v kerneli 2.6.3 nenasiel driver. Server bude aplikacny cize bude dost narocny na rychlost rozhrania.
-
'Kockac' Mato K. (neregistrovaný)
U nas pouzivame na backbone uz mnou spominane Intely (fxp driver pod FBSD) a ja osobne by som sa uberal tym smerom. Bohuzial neviem povedat, ako su na tom gigabitove.
Asi som uz unaveny, ale nenasiel som tam OS. Ak chcete pouzivat FreeBSD, doporucujem kartu, ktora podporuje DEVICE_POLLING (za teoreticke marginalne zvysenie stratovosti, ktore som ale este nepozoroval, vyrazne znizila zataz stroja pri spracovavani sietoveho trafficu). Myslim, ze to podporuje vacsina gigabitov, zoznam 100viek je v polling(4). -
Michal Kára (neregistrovaný)
Bylo tam prave to RTLko... Zkusil jsem tam ted dat 3Com905ku. Podle mne se to o neco malo zlepsilo (ony ty vysledky jsou ponekud fuzzy :-|), ale nijak vyrazne. 950 requestu za sekundu to porad nezvladalo. A volnou EtherExpress tady k dispozici nemam.
(BTW, s tou e100 jsem mel docela problemy, protoze jsem mel dve e100 karty, ktere se pod linuxem obcas nenahodily. Pod Woknama to jelo OK. Vyresil jsem to tak, ze jsem delal ifdown/ifdup dokud nezacaly na karte nabihat citace prijatych packetu :-) -
CrONiN (neregistrovaný)
(Just for fun.)
Vysledky su fuzzy? Vysledky su crisp hodnoty, akurat maju nejake statisticke rozdelenie nahodnej premennej. Fuzzy by v tomto pripade mohla byt interpretacia vysledkov, kedy by ste nadefinovali fuzzy mnoziny "A = vykonny server" a "B = slaby server", pricom by ste definovali funkcie prislusnosti k danym fuzzy mnozinam a to tak, ze by jeden vysledok mohol patrit napr. na 0,2 do mnoziny A a na 0,6 do mnoziny B. Ak by pre kazdy vysledok platilo ze stupen prislusnosti k A plus stupen prislusnosti k B je rovny jednej, vytvorili by ste dokonca fuzzy particiu.
Samozrejme, z matematickeho hladiska mozno brat kazde crisp mnoziny ako specialny pripad fuzzy mnozin. V danom pripade by mozno bolo namieste pracovat s tzv. fuzzy cislami, co sa ale v praxi -- zial -- malokde pouziva. -
Michal Kára (neregistrovaný)
Ja vim, co je to fuzzy v matematickem slova smyslu, mam dokonce zkousku z fuzzy logiky ;-) Ja to myslel spis v puvodnim anglickem smyslu, t.j. "mlhave". Proste kolem toho bodu kde se to lame je to na ostri noze a obcas to ten pocet requestu zvladne a obcas ne. Ja jsem to bral tak, ze jsem pustil cca 5 testu a pokud to alespon jeden z nich zvladlo, tak jsem to bral.
-
lzap (neregistrovaný)
No -- není efektivnější, ani být nemůže. Byl to specifický problém týkající se slabé podpory vláken na Linuxu, s příchodem nových jader a Apache 2.0 už je to eliminováno, takže tam se dají použít vlákna...
Ty mají ale (přes svoji lepší efektivitu) také řadu nevýhod. Proto se to řeší tak, že se třeba dá zrovna ten Apache 2 nastavit tak, že se spustí třeba 50 forků a v každém po deseti vláknech... -
Lubos (neregistrovaný)
Neni obecne, je to pomerne slozitejsi zalezitost.
Tady je skvely clanek k teto problematice vztazen k OS jako Windows/Linux kernel 2.4 a 2.6 a FreeBSD. V podstate neco jako tenhle clanek ale imho mnohem lepsi.
Nevim jestli je to tam, nebo jeste nekde jinde jsem to videl, a treba do 400 procesu bylo lepsi pres thready a pak fork
http://bulk.fefe.de/scalable-networking.pdf -
Ondřej Válek (neregistrovaný)
Ceky test je postaveny na requestech na statickou stranku. V realu je IMHO vetsina obsahu generovana dynamicky. Proto by me zajimal nejaky zatezovy test, kde by se posilal request na stranku generovanou v PHP.
Apache je urcite dobre optimalizovany, jakou asi udela paseku, kdyz bude potreba vygenerovat nekolik set takovych stranek za vterinu (priklad ze zivota - na CNN se objevi zprava o teroristickem utoku a kazdy ji chce videt).
Nechcete to take vyzkouset? Pripadne nevite, jestli uz nekdo tyto testy nepublikoval? -
Michal Kára (neregistrovaný)
IMHO dynamicke generovani obsahu bude mit pouze jeden efekt - procesor bude travit (pomerne) vice casu generovanim toho obsahu a mene v systemu. Tedy stravi se vice casu behem (treba) v PHP interpretru a mene v systemu. Ovsem jelikoz je ten interpreter na obou platformach stejny, tak se pouze zmensi rozdil mezi platformami, nic vic.
-
Martin Kuchař (neregistrovaný)
Tak to ale nefunguje. Na velkych serverech se stranka dynamicky vygeneruje jen jednou a stane se z ni stranka staticka. Kacdemu dalsimu uzivateli se posila uz ta staticka.
Bud se to resi pomoci cache (Zend etc.), nebo se primo necha systemem vygenerovat sada statickych stranek po kazde zmene.
Generovat stranku kazdemu, i kdyz vime, ze vysledny dokument bude stejny je blbost, ikdyz to IMHO delame skoro vsichni :-) -
Michal Kára (neregistrovaný)
Meli jste pravdu, (optimalizovane) FreeBSD 4.9 je vyrazne rychlejsi, nez 5.2. Dokazal jsem z nej vymacknout az 1400 requestu za sekundu. Ale bylo to uz hodne na hranici, jak ukazuje vypis iostat. Bohuzel jsem pri testech Linuxu nepoustel vmstat, takze od nej vysledky nemam :-|
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
0 26 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100
0 26 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100
0 26 90.67 1 0.09 0.00 0 0.00 0.00 0 0.00 41 0 30 18 11
0 26 128.00 1 0.12 0.00 0 0.00 0.00 0 0.00 39 0 30 25 6
0 25 128.00 1 0.12 0.00 0 0.00 0.00 0 0.00 42 0 35 22 0
0 25 128.00 1 0.08 0.00 0 0.00 0.00 0 0.00 43 0 35 22 1
0 26 128.00 1 0.12 0.00 0 0.00 0.00 0 0.00 43 0 31 19 7
0 25 128.00 1 0.12 0.00 0 0.00 0.00 0 0.00 43 0 35 21 2
0 25 83.20 2 0.13 0.00 0 0.00 0.00 0 0.00 47 0 27 26 0
0 22 58.29 2 0.12 0.00 0 0.00 0.00 0 0.00 45 0 32 23 0 -
laNDRu (neregistrovaný)
ahoj,mam dotaz: Byla pri testu FBSD 5.2 pouzita defaultni thread knihovna libc_r anebo libkse? Podle nekterych nazoru by taktez mela vest ke zvyseni vykonu. V 5-current je jiz stejne jako ULE defaultni, viz(libkse): http://www.bsdforums.org/forums/showthread.php?threadid=18469
Ad.4.x rada.Lepsi vykon je skutecne znat pri praci i bez mereni;-) -
junix (neregistrovaný)
Jo, osobne by me taky opravdu zajimalo i toto srovnani. Pak bych se take primlouval za nejake ty dynamicke stranky (rekneme PHP/ASP s ekvivalentni funkcionalitou). Ovsem narozdil od uvedeneho testu, tady mam urcitou predstavu (podlozenou zkusenostmi z praxe), jak to dopadne. Bohuzel jsem nemel prilezitost videt srovnani v uplne stejnych podminkach (HW, zatez).
-
Michal (neregistrovaný)
My jsem takove testy delali a ASP vyslo o dost lepe ale mohlo se tam projevit to, ze jako databaze (hojne vyuzivana) byl pouzit MS SQL server (bezici na jinem pocitaci nez webserver). Doba odezvy IISka (verze z win2003) i pocet zvladnutych requestu byl az o 25% lepsi nez u Apache2+PHP. Na druhou stranu je treba rict, ze Apache se behem testu choval naprosto korektne kdezto IISko dvakrat behem testu prestalo reagovat a musel se ten web (prislusny dllhost) restartovat.
Pak jsem si sedl k te ASP verzi a pomoci CaprockDictionary (free komponenta pro perzistentni hashtable) implementoval cachovani. Vykon sel nahoru temer radove. PHPkari se snazili totez implementovat pomoci shmem ale nepodarilo se jim to. -
neologism (neregistrovaný)
k hodnoceni asi toto:
1) fbsd 5.x ma zapnuto VIC debugovacich veci nez linux nebo 4.x (KASSERTy apod.)
2) test je zameren na mikrobenchmarky, kde jak znamo linux zari (pac to pomaha prodavat produkt) zatimco v realnem zatizeni (coz sorry ale 1500B staticka stranka NENI) to uz tak slavne neni. ale uznavam ze momentalne muze byt 5.x slabsi (nemyslim si to ale byt to tak muze). jenze z takovehoto porovnani vychazi jako nejhorsi solaris apod. ;)
3) vite vubec proc existuje 5.x? co je v ni dobreho/noveho? 5.x ma napr. KSE threading, ktery imho zlepsi (u apache 2.x) vykon dost radikalne (bude to threadovat v podstate jen v userspace)
vic mne asi uz nic nenapada ;) -
Michal Kára (neregistrovaný)
Ad 2: A co treba takovy image server - tedy server poskytujici obrazky (img.centrum.cz, 1.im.cz (image server Seznamu))? Je to staticky obsah, prumerna velikost obrazku nebude zas tak daleko od pravdy a navic se stejne hodne casto nebude obrazek ani prenaset s tim, ze "Not modified".
I kdyz je fakt, ze na takovy ucel bych Apache nepouzil. A ohledne dynamickeho zatizeni - viz moje poznamky predtim. A navic je u toho dynamickeho zatizeni hodne problematicke udelat nejaky alespon trochu typicky benchmark :-/
Jinak tedy tomuhle bych mikrotest zrovna nerikal. Mikrotest je podle mne http://bulk.fefe.de/scalability/. Tohle je makrotest. Samozrejme se muzeme bavit o typicnosti testu, ale to, bohuzel, u kazdeho takoveho testu, neb pouziti OS je siroke :-( -
Vašek (neregistrovaný)
Za ten test diky. Myslim ale, ze nemate pravdu, kdyz se domnivate, ze pri dynamicke zatezi se bude rozdil mezi OS smazavat. Bude-li dostatek zdroju, pak mozna ano, ale v momente krajnesiho vyuziti PC bude hodne zalezet na dalsich vlatnostech OS a rozdily se urcite projevi. Priznam se, ze by mne velmi zajimal podobny test na PC, ktere je na stiru s RAM (tam se obvyklem casem dostanu).
-
Michal Kára (neregistrovaný)
Dokud jsem delal zatizene WWW servery, tak jsem mel politiku, ze alokovana pamet by nemela ani v denni spicce presahnout polovinu dostupne pameti. I kdyz je pravda, ze jsem nemel vylozene pametove narocne aplikace.
Podle mne bude existovat urcita hranice obsazeni pameti, kdy zacne cely system odpovidat pomaleji (=> pujde do kytek). Ta hranice dost zavisi na vyuziti systemu - samotny beh WWW serveru asi nebude potrebovat moc volne pameti (=cache). Ale pokud na tomtez systemu budete mit databazi, kterou budete vyuzivat, tak se snizeni pameti pro diskovou cache silne negativne odrazi na jejim vykonu. A to rozhodne o moc drive, nez dojde byt jen k naznaku vycerpani pameti. -
Michal Kára (neregistrovaný)
No, tak nejak :-) Co jsem tak delal svoje testy. rada 2.0 je zhruba stejne rychla jako 1.3. Mozna pri spravnem nakonfigurovani (spravny pomer threadu a procesu) rychlejsi bude... ale hlavni prinos 2.0 vidim ve zlepsene architekture, hlavne v tom, ze se pri pridavani filtru obsahu nemusi patchovat puvodni zdrojak :-)
ČLÁNKY DO MAILU