FreeBSD 8.1/pf performance

[Dan Lukes]

Jan Dušátko wrote:
> na tomto interface je poveseny stavovy packet filter, kde dovnitr je zakaz s
> vyjimkou portu 22 a 80. Ven je povoleno vse.

> V uvedene konfiguraci dokaze system obhodpodarit cca 2000-3000 klientu (cca
> 10000-15000 packet/sec)

> Pokud spustim jeste fronty a nahodne rozdelovani  (duvodem je vysoke
> vytezovani linky nekterymi klienty), vykonnost system poklesne a dokaze
> obhospodarit cca 1000-1500 klientu (cca 3000-5000 packet/sec)

> Vtip nastane, pokud vypnu pf. V takovem okamziku se bavim o obsluze cca 20
> 000 klientu nez narazim na strop aplikace a zadne problem s timeouty.

Zatim mas problem porad jeste strasne siroky. Do hry nam vstupuje 
"lagg", "stavovost", "modulate state", "altq" a nakonec cely "pf" framework.

Pokud nenajdes nekoho, kdo na stejny problem uz narazil a tudiz ma 
analyzu provedenou a budes si ji muset delat sam, obavam se,z ew jedina 
cesta bude pres izolaci problemu. To znamena zjistit jaky vliv ma na 
chovani "stavovost", jestli se problem nahodou zazracne nevyresi 
nahradou pf za ipfw, ...

Horsi je, ze nelze vyloucit, ze vysledny efekt spoluvytvari vic vlivu.

To, ze vypnuti "pf" prinese vyrazne zrychleni ale neni nijak prekvapive. 
Ja sice PF nepouzivam, ale pokdu si to vybavuju dobre, tak interne je to 
implementovano tak, ze pravidla, ktera ty pises, jsou v jadre ulozena ve 
forme pseudokodu a u kazdeho pakety internpret bezici nad timto 
pseudokodem rozhoduje "co dal". Pocet procesorovych instrukci, ktere 
pruchod paketu vyzaduje, se tim zvysuje opravdu zasadne.

Mozna by mohl byt pekny a velmi uzitecny projekt vytvorit kompilator 
pravidel do nativniho kodu procesoru - aby se obesla nutnost opakovane 
interpretace mezikodu. A kdyby ten kompilator vytvarel kod 
optimalizovany ...

Ale nepocitam s tim, ze byses do reseni problemu pustil tudy ;-) 
Nakonec, nevime ani jak velky podil na problemu ma prave interpretace 
pravidel.

Na takto vyznamne uzivane masine ti to ladeni rozhodne nezavidim, ale 
nevidim jinou cestu jak se dobrat vysledku nez pokusovani s ruznymi 
nastavenimi. Musel bysis vedle postavit testovaci stroj a dokazat proti 
nemu vytvaret odpovidajici zatizeni - a to nevim, jestli mas takovou 
moznost.

> Dalsi zalezitosti je parovani sitovek pod vysokou zatezi. Z praxe vim, ze
> parovani interface casto znamena vykon dolu, nekdy az na tretinu puvodniho

No, to je ztrata, ktera je tolerovatelna jen pokud ten vykon nepotrebujes.

V opacnem pripade je treba zvazit, zda jsou prostredky zvoleny dobre. 
Zalezi proti vypadkum kterych komponent se presne jistis , ale mam za 
dost dobre mozne, ze jak 'lagg' je mozna pro dany ucel zbytecne slozity 
nastroj - a overhead souvisi prave s temi funkcemi, ktere mozna nakonec 
vubec nepotrebujes ...

Pokud neni cilem zvyseni pruchodnosti (agregace) ale failover, pak bych 
spis nez po lagg koukal pro bridge+stp. Tam bych cekal overhead mensi, 
protoze v kazdy okamzik efektivne funguje jen jedna z obou karet coz 
logiku zpracovani zjednodusuje a cekal bych overhead spis o dost mensi 
nez 66% ...


				Dan