Re: [BSD] Levelezés IMAP-al

[Szabados Jozsef]

Hali Balsa, meg mindenki,

A hup-on irkalt peldat megneztem, igaz az egy eleg extrem pelda exim vs.
postfix temakorben. En meg nem akadtam olyan problemaba, amit nem tudtam
megoldani postfixxel. (Majd ha lesz gondolok az eximre ;-).

Az emlitett terhelesi pelda (100 exer level/nap) szerintem nagyon nulla
ahhoz, hogy barmely mta-nak kulonosebb gondot okozhasson. De ket pelda jut
hirtelen eszembe. Erdemes megnezni egy FreeBSD-s levlistas, meg egy
securityfocus-os levlistas level fejlecet, hogy milyen mat-k vannak ott.
Nekem nincs tul sok jo velemenyem az eximrol terhelhetosegileg, de ha nem
haragszotok meg politikailag nem irnek rola ;-))).

Egyszer teszteltem egy par mta-t. Az eredmeny (bocs rtf ben volt, a
kopipeszt miat egy kicsit szetcsuszott):

[Na jo lehet vitazni, ugyis uborkaszezon van ;-]

udv,
Szabados Jozsef

###########
A teszt célja: az ingyenes mta-k teljesítményének az összehasonlítása.
Elsosorban a levélfogadás és levélkézbesítés nagy terhelésu környezetben
való muködésének vizsgálata.

A teszt leírása: localhoston keresztül, egy levélküldo script (netcat)
rákapcsolódott a 127.0.0.1-es loopback interfész 25-ös portjára, és elküldte
a levelet, egy idozíto script meg ezt a scriptet hívta meg 10000-szer. A
mérési ido kezdete az idozíto script indulása, a vége pedig annak a
befejezése.

MTA load* levél** ido*** mód**** megjegyzés

qmail 150 236 40mp párhuzamos *****

qmail 0-1 9936 50:27 soros

sendmail 8-15 5683 15:53 párhuzamos

sendmail 1-3 10000 24:10 soros

postfix 1-6 10000 9:41 párhuzamos

postfix 2-6 10000 19:19 soros

exim 20-325 350 3:25 párhuzamos swap elfogy, teszt nem fut le

exim 1-2 10000 27:25 soros



Magyarázat:

* - load CPU terhelés (uptime program kimenetét figyelve)

** - levél a 10000 levélbol ennyi érkezett meg

*** - ido az elso levél elindulásától, az utolsó elküldéséig

**** - mód soros: egyik levél elmegy, és csak utána a következo

párhuzamos: párhuzamosan indulnak a levelek

***** qmail párhuzamos muködése:

az inetd-n keresztül indítva: az inetd alól elfogy a memória, négyszer
újraindítva a teszt során

a tcpserveren keresztül indítva: a swap terület elfogy, a kernel naplózza, a
CPU terheltségétol a gép

használhatatlanná válik



Exim: a párhzamos esetben naplózta, hogy sok a kapcsolat, a kernel meg
naplózta, hogy elfogyott a swap terület. A nagyon leterhelt rendszer miatt
leállitottam a tesztet.

Postfix: érdekes a muködése. Párhuzamos muködés esetén, 8 perc 33 másodperc
alatt fogadja az összes levelet, de ez ido alatt a 10000 levélbol körülbelül
1500-at kezbesít (Kb. 1 MB a mailbox) majd a következo körülbelül 12 perc
alatt a fennmaradó 8500-at (Kb. 5 MB, így lesz a mailbox kb. 6 MB). A többi
MTA megpróbálja többé kevésbé üresen tartani a queuet.

Végeredmény:

Soros muködés esetén midengyik megfeleloen muködik.

Párhuzamos esetben a maximált párhuzamos kapcsolatok miatt a levélveszteség
növekszik (ami végül is nem olyan nagy baj, az smtp "store and forward"
muködése miatt, tulajdonképpen nem tunik el levél két szerver között). A
kézbesítési arányt javítani lehet nagy teljesítményre való optimalizációval.

Soros: Párhuzamos

1. postfix 1. postfix

2. sendmail 2. sendmail

3. exim 3-4. exim, qmail

4. qmail

Párhuzamos 3-4: nincs igazán nagy elonye egyiknek se. Optimalizációval
biztos nagyobb különbség lett volna köztük.

Konfiguráció: többé-kevésbé igyekeztem az alapértelmezett beállításokat
meghagyni, a pontosabb összehasonlíthatóság kedvéért.