Názory k článku
Jak jsem instaloval a testoval FreeBSD 5.2 (2)

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)...

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.

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.

Mne v tom testovani chybi sloupecek s tuningovanou FreeBSD release 4.9 vhodnou na produkcni servery, neslo by to jeste doplnit?

Principielne by to slo, testovaci pocitac jeste mam, jen bych ho musel reinstalovat na 4.9. Myslite, ze bude mit vyssi vykon nez 5.2?

Pravdepodobne ano; nedostatocna vykonnost sa udava ako jeden z dovodov, preco zatial 5.X nie je HEAD.

Vyborny clanok, presne na taky som cakal. Este by ma zaujimalo porovnanie s Win2k a pripadne s M$ IIS ;o)

Zaujimave by tiez mohlo byt porovnanie optimalizovanych jadier.

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.

Zdravim,
chetl bych se zeptat na neco toruchu jineho okolo FreeBSD. Netusite jestli jde rozbehnout na 4Mb pameti.
Samozrejme se to tyka pouziti pro embeded aplikace.
Staci mi aby umelo sit+ide. Linux s jadrem 2.0.x takhle pouzivam, ale neni to uplne ono.Dan

Na instalaci je třeba aspoň 5MB. Pro běh by měly 4 MB stačit, ale asi bude třeba zkompilovat jádro a vyházet nepoužívané volby. Viz
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/install.html#FOUR-MEG-RAM-INSTALL

Zdravim,

mam prosbu, neslo by otestovat i OpenBSD? Celkem by me to zajimalo, jak na tom je. D.

Podle testu uvedenych na http://bulk.fefe.de/scalability/ by na tom melo byt spis hure, nez FreeBSD.

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 :(

Provozoval jsem dlouhou dobu nekolik (cca 30) zatizenych pocitacu ale uvedene problemy jsem nikdy nepozoroval. A to i pres uptime nekolik mesicu. Nevyzirala tu pamet spis nejaka aplikace s memory leakem?

Myslim, ze to tak presne je. Mam k tomu jednu zkusenost. Jeste loni jsem mel na jednom pocitaci stareho RedHata 7.3 s KDE a jednou za cas jsem se musel odhlasit a prihlasit, protoze cele GUI bylo desne pomale. Jadro si ale chrochtalo i pri uptime 150 dni.

- 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.

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.

Mam Debiana stable verzi, tedy jadro 2.4.18, uptime je 130 dnu a zadne zpomaleni diky cachovani se nedeje. Pouzivam ho jako desktop, takze dlouhodoby proces mam akorat mprime, ktery bezi momentalne 72134 min. Takze si myslim, ze je to chyba apliakce, ne jadra.

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..)

no neviem, redhat 7.3 na starom pentiu, kernel 2.4.18-3, uptime 454 dni... bezi na tom kopa javy a je to stale uplne v pohode... :-D

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 :)

Nie je pravda, ze 5.x je o rad pomalsia, podla mojich skusenosti je minimalne na rovnakej urovni, avsak ma este muchy.

ani ja jsem na workstation zadne zpomaleni nezaznamenal, ale je pravda ze jsem to nijak netestoval a jestli jsem cekal na zkompilovani kernelu o 10min dele, tak jsem si toho ani nevsimnul :)

prodavam, jen jak jsem nakoupil

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. :)

Nehnevajte sa, ale NetBSD 1.6 ani FreeBSD 5 uz BSD-like init skripty nepouzivaju, takze o com ma byt ten druhy bod? ;-)

Doporucuju docist diskusi az do konce :)
Jinak cistota architektury neznamena lepsi vykon. Podivejte se na GNU Hurd :)

zajimal by me priklad/y, podelte te se prosim ...

Mikrokernely? Teoreticky uzasne, prakticky nic moc...

Na cetne zadosti se asi zkusim dnes odpoledne poprat s instalaci 4.9 a provest testy na ni.

Pokud do te doby nekoho napadne jeste nejaka optimalizace 5.2ky, sem s ni. Pak uz se mi ji nebude chtit kvuli tomu testu znovu instalovat ;-)

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.

Mam zato, ze testy by se meli priblizovat praktickemu pouzivani. Takze volba apache je spravna.

Jasne, ze s jinym/jinak nastavenym Apachem by se dalo dosahnout lepsich vysledku. Ale o to neslo.

Pokud rozlustite vypis vmstatu uvedenyv clanku, uvidite, ze v systemu to travilo zhruba 2/3 casu. Takze podle mne ten test system docela proveril...

Jo ty výpisy by byly určitě zajímavé i z Linuxu. A na FreeBSD by bylo hezké ještě pustit iostat, který rozlišuje na CPU system a interrupt.

Po ENABLE_VFS_IOOPT v kernelu je třeba ještě nastavit sysctl vfs.ioopt=1

Jsem zatim uzivatel FreeBSD spise lamoviteho charakteru. Ale vim, ze FreeBSD implicitne zahrnuje radu mechanismu proti DOS utokum na urovni IP (SYN floody, ICMP floody, acertvijake dalsi floody). Domnivam se, ze tento fakt mohl zkreslit vysledky testu.

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.

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

nesel by dat ke stahnuti ten konfigurak bsd jadra? jen pro zajimavost.

http://lemming.webpark.cz/mykernel

403 Access forbidden

Zajimave. Asi vas prohlizec nevedel co s typem 'unknown'. Prejmenoval jsem to na http://lemming.webpark.cz/mykernel.txt

http://lemming.webpark.cz/mykernel.txt

You don't have permission to access /mykernel.txt on this server.

mozilla 1.7a

Tak vam to asi blokuje Vase proxy... Mne to normalne funguje.

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 :-)

To ne :-)

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 !

Zajimave. Pres den jsem se na ten konfigurak bez problemu dostal, a ted mi to taky pise "Access forbidden" :(

Jaká síťová karta je na testovacím stroji?

Mě by to zajímalo obecně. Jaký vliv mají na výkonost různé síťové karty tedy např 100 Mbit/s realtek a 100 Mbit/s 3COM atd... (samozřejmě vše PCI :-) je mezi nimy rozdíl ve výkonu? A jak je to v Linuxu/BSD a ve Win. Nebo je rozdíl opravdu jen cena?

Michal

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. :-)

myslim ze realtek 8139 je jedna z kariet pre ktoru FreeBSD podporuje "polling" mod, co by moholo trochu pomoct pri zvysovani vykonu...

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.

3com je smejd preco ? Ma v sebe veci, o ktorych sa 8139 ani nesniva...
Zase taka nepodlozene tvrdenie.

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.

mozes ma prist navstivit s neaku 3comou a ukazem ti (a mozes si aj vyskusat) vela situacii, kde s nou budes mat problemy... akekolvek ine sietove karty vcetne tych najlacnejsich shitov rtl8139 tu problemy nemaju, takze ...

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?

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.

To neni uplne presne, v notesu mam 3c2000 zalozena na cipu 3c940, pouziva se standardni modul sk98lin.

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).

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 :-)

(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.

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.

A co otestovat samotne sitove karty ???
Uz dlouho me, a verim ze nejen me, ta otazka zajima, tj. jestli je vubec mezi sitovymi kartami rozdil a jaky, pripadne jak vyrazne, pokud vubec, se projevuje na sitovem vykonu.

Zajimalo by me jak je na tom solaris x86 v porovnani s linuxem. Nevite?

Pise sa o threadoch ... neda sa nastavit aby Apache procesy forkoval, miesto aby to boli thready ? Pretoze od cca 400 konekcii je lepsi fork.
Kdesi na internete su vysledky takychto testov.

Oni se forkuji, to bylo trochu nepresne vyjadreni. Ale ten apache byl nastaveny tak, ze tech 512 procesu bylo spustenych neustale (MaxClients 512, StartServers 512, MinSpareServers 512 ...).

Proč je fork efektivnější?

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...

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

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?

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.

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 :-)

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

Dik za dodatecne mereni 4.9, hned jsou vysledky zajimavejsi. Mne hodne zajimalo prave porovnani 4.9 a 5.2.

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;-)

Popravde receno nevim, nic ohledne libc knihovny jsem nemenil. (Na druhou stranu mi neprijde, ze by libc mela v testu az takovy vliv na vykon.)

libc_r je reentrantni knihovna ktera slouzi pro implementaci threadingu (v tomto kontextu je to ale irelevantni pac apache 1.x pouziva procesy a ne thready)

tak proc autor na zacatku mluvi o threadech a ne procesech?

Uz jsem psal, ze to je terminologicka nepresnost. Apache 1.3 (pokud vim) thready vyuzivat neumi, jen procesy. (Na druhou stranu formulace "bezelo tam 512 procesu Apache" by mi prisla zvlastni...)

linux ? freebsd ? zdaleka nejlepsi vykon ma windows 2000 server service pack 4 s IIS vyladenym jako prase

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).

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.

Když už jiné platformy, tak pak by se měl testoval i Netware 6.0 (s integrovaným Apache 1.x) nebo Netware 6.5 (kde by se to snad pro test dalo downgradnout)

No shmem myslim neni presne to co mate na mysli. PHP ma cachovaci nastroj Zend Cache (TM), ktery zvedne vykon take temer radove. Bohuzel ten zdarma neni.
Jestli mate na mysli SysV shmem, tak to je neco jineho. Shared memory slouzi ke sdileni dat ruznymi procesy.

Jj, ovsem existuje ekvivalenta Zendu, turck-mmcache. Nemel jsem moznost porovnat se Zendem, nicmene turck zveda vykon taky zasadne, nekdy o rad - ovsem je fakt, ze vetsina veci je nejvic zpomalovana konexemi s db a tomu zadne cachovani neodpomuze...

No, jak s kterymy. Pokud se jedna treba o Oracle, tak opravdu hodne pomuze pouziti persistentni konexe.
Naopak treba s MySQL to ma spis opacny vliv, protoze si s persistentni konexi nak neumi poradit.

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 ;)

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 :-(

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).

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.

jen poznamka, kdyz mluvite o optimalizaci jadra, proc v tom konfiguraku nechavate vsechny ty ovladace SCSI, RAID, PCMCIA, sitovek, usb, splash screen, firewire, atd.., moc vysledkum nepomuze, ale presto :)). jinak supr clanek.

Protoze se mi nechtelo to vsechno prochazet, zkoumat, vyhazovat,riskovat, ze mi novy kernel nepojede :-)

AFAIK, existence ovladace (treba pro SCSI) v jadru nema na vykon WWW serveru zadny vliv.

Proc byl k testovani pouzit Apache rady 1.3, kdyz je k dispozici rada 2.0? Je rada 2.0 horsi? Nebo je to jen neco jako rada 5.x u FreeBSD?

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 :-)

Trochu OT, ale zajimalo by mne, jestli nekdo ma zkusenost s obema systemy a mohl by vyslovit (subjektivni) nazor, ktery system se mu jevi stabilnejsi. A to jak serveru, tak desktopu.