MPP vs. ‘open source’ spamszűrők
A Virus Bulletin: a spamszűrők együtt jobbak, ill. a Hány licence kell neked? írások alapján felbuzdúlva végeztem egy gyors tesztet az MPP-vel ill. egy ‘open source’ spamszűrővel.
Hogy a teszt eredmények valóban összevethetőek legyenek, végül mégsem az MPP VMware appliance-ot használtam, mert abban rengeteg egyéb funkció is megtalálható (pl. karantén, archiválás, …), ami megnehezítené az összehasonlítást.
Ezért letöltöttem az MPP ver. 4.20.0, rc1, Tue Aug 25 13:39:17 EDT 2009 [Linux 2.6.12-1.1381_FC3 i686] verziójú linuxos verzióját, és azt használtam. Nem telepítettem viszont az mppmanager-t, mivel nem volt most szükségem a szolgáltatásaira, és a MySQL szervert sem használta az MPP.
A teszt környezet egy WMware-ben futtatott CentOS 5.4 volt, ami 768 MB RAM-mal gazdálkodhatott. A teszt során összesen 9.6k levelet küldtem a rendszerre 10 szálon (=SMTP kapcsolaton) át, kb. fele-fele arányban jó ill. spam leveleket.
A tesztnek két célja volt. Az első, bizonyítani azt, hogy az MPP esetében nem igaz az a tétel, hogy ha több szűrőmotort használunk, akkor a szűrőmotorok számával egyenes arányban csökkenne az áteresztőképesség, azaz pl. 10 szűrőmotor tizedakkora teljesítményt eredményez. A másik pedig az, hogy képet kapjak a Cloudmark teljesítményéről. Azt is szeretném már az elején megjegyezni, hogy a teszt nem tért ki az egyes spamszűrő megoldások pontosságára.
A leveleket – privacy rulez – minden esetben ssh tunnel-en keresztül küldtem a VMware-ben futó programoknak, és minden levelet – függetlenül attól, hogy spam vagy sem – a /dev/null-ba irányítottam.
Két fajta tesztet végeztem. A TESZT1 során közvetlenül a 127.0.0.1:10025/tcp-re (azaz a spamszűrőre) irányítottam a leveleket, amelyek utána a 127.0.0.1:10026/tcp-n futó postfix példányhoz kerültek, ami a /dev/null-ba írta mindet.
A TESZT2 során pedig a szokásos módon a postfix kapta meg a leveleket a 127.0.0.1:25/tcp-n, amelyeket átadott a spamszűrőnek, az pedig visszaadta a postfix-nek, végül ebben az esetben is a /dev/null volt a végállomás.
TESZT1 / MPP:
Két kört is mentem. Először a <scan_engines>cloudmark, clamav</scan_engines> beállítással. Ebben az esetben a teszt időtartama 08:41 perc volt (15:25:40 – 15:34:21). A második körben kihagytam a clamav-ot, és csak a cloudmark eredményére voltam kiváncsi: <scan_engines>cloudmark</scan_engines>. Ebben az esetben rövidebb ideig tartott a teszt: 08:20 percig (16:27:16 – 16:35:36).
TESZT2 / MPP:
Itt már csak a cloudmark-ra koncentráltam, és a 9.6k levél /dev/null-ba továbbításához 09:49 percre (16:05:28 – 16:15:17) volt szükség.
Fontosnak tartom megjegyezni, hogy az mppd.conf konfigurációjában a használt szűrőmotorok felsorolásán kívül semmit nem módosítottam. Az MPP alapesetben debug módban loggolt. Ha ezt lejjebb vettem volna, (valamennyivel) biztosan nőtt volna a teljesítmény.
Az mppd.conf.xml tekerése közben észrevettem, hogy csak 2 szálon dolgozta fel az MPP a leveleket (processing_threads=2). Ezért, ha már itt voltam, ezt felemeltem 10-re, ill. csak a hibákat naplózta az MPP (logging=ERROR). A TESZT2 feladatot ebben az esetben tehát 08:26 perc (22:27:44 – 22:36:10) alatt végezte el az MPP.
A kihívó
Az álruhás versenyző pedig a clapf legutolsó (0.4.3.1) verziója volt az alábbi konfiggal, ill. fordítási paraméretekkel:
clapf_header_field=X-Clapf-spamicity: clapf_spam_header_field=X-Clapf-spamicity: Yes group_type=0 hostid=av-engine.localhost locale= mysqlsocket=/tmp/mysql.sock mysqluser=clapf mysqlpwd=********* mysqldb=clapf mysql_connect_timeout=2 penalize_embed_images=1 penalize_images=1 penalize_octet_stream=1 possible_spam_limit=0.8000 possible_spam_subject_prefix=[spam???] quarantine_dir=/var/lib/clapf/quarantine spam_overall_limit=0.92 spaminess_oblivion_limit=1.01 store_metadata=0 store_only_spam=0 training_mode=0 update_tokens=0 use_antispam=1 verbosity=1
./configure --localstatedir=/var \ --with-userdb=mysql \ --enable-rbl \ --enable-policy \ --enable-whitelist \ --with-tokendb=mysql \ --enable-static-build \ --with-store=fs \ --enable-lmtp
A clapf nem használta a clamd-t, nem frissítette a tokeneket, és minden adatot MySQL 5.4.3-beta tárolt.
TESZT1 / clapf:
08:02 perc (15:54:00 – 16:02:02) alatt végzett a ~9.6k levéllel.
TESZT2 / clapf:
07:37 percig (16:16:58 – 16:24:35) tartott, amíg elintézte a leveleket.
Az eredmények táblázatban
| TESZT1 | TESZT2 | |
| Cloudmark | 19.33* – 25.50** | 16.41* – 19.10** |
| clapf | 20.05 | 21.15 |
1. táblázat: Az MPP és a clapf levéláteresztő képessége [levél/sec]
*: processing_threads=2, logging=DEBUG
**: processing_threads=10, logging=ERROR
Következtetések/értékelés/magyarázkodás/….
Az eredmények megcáfolják azt a korábbi kijelentést, miszerint “az MPP-re váltáskor nem ritkán tapasztalunk 10-100x-os teljesítmény (áteresztő képesség) növekedést a korábbi opensource megoldásokhoz képest, a számos szűrőmotor ellenére.”
Noha a TESZT1-ben az MPP/Cloudmark kombó ~25%-ot rávert a clapf-ra, azonban relevánsabb a TESZT2 eredménye (mert a gyakorlatban sosem a spamszűrő fogadja a leveleket, hanem egy MTA), ahol a clapf egy szerényebb 10%-kal ért el nagyobb teljesítményt az MPP/Cloudmark duónál.
Tehát az előbbi állítás helyesen így hangzik: “Ha az MPP csak a Cloudmark szűrőmotort használja, akkor a teljesítménye nem marad el sokkal a clapf-tól”.
Figyelemre méltó, hogy amíg az MPP teljesítménye csökken, ha a levelet a postfix fogadja (és nem az MPP), addig a clapf esetében jobban jártunk. Utóbbinak az a magyarázata, hogy a clapf a TESZT1 esetén minden levél esetén fork()-olt egyet. Viszont a postfix, ha nő a terhelés, akkor ugyanazt az s/lmtp kapcsolatot a tartalomszűrő felé több levél esetében is fel tudja használni. Így amit veszítünk a 25/tcp-n hallgató postfix beiktatásával, azt bőven megnyerjük a clapf kevesebb fork()-olásával. Az MPP viszont nem használja a postfix lmtp connection cache-t – az MPP telepítője egészen konkrétan kikapcsolja.
A TESZT2 során egy érdekes jelenségre is felfigyeltem. A működés során a postfix fogadja a leveleket SMTP protokollon, elkezdi gyűjteni a queue-jába, majd érzés szerint tovább adja a tartalomszűrőnek. Az MPP esetében a postfix rövidebb idő átvette a leveleket az SMTP klienstől, viszont amikor elment az utolsó levél is a kliensről, azaz a postfix nem vett át több levelet a hálózatról, akkor a queue mérete ~4k levél volt. A clapf esetén tovább tartott, amíg a 9.6k levelet átvette, viszont a queue mérete nem ment 100 levél fölé, és összességében rövidebb idő alatt elért az utolsó levél is a /dev/null-ba.
A történeti hűség kedvéért meg kell jegyezni, hogy a load magasabb volt, amikor a clapf vizsgálta a leveleket, ill. amikor 10 MPP szál végezte a feldolgozást, akkor a queue mérete kb. akkora volt (n*10), mint a clapf esetében, viszont az MPP esetében is megnőtt a load.
A legfontosabb viszont még csak most jön. Az MPP tesztben mindössze egyetlen szűrőmotort használtam. Az MPP viszont használni képes még sok más szűrőmotort is, pl. Commtouch, mailshell, … és a jó öreg SpamAssassin démon változatát (spamd) is. Az admin felületen be lehet állítani, hogy milyen vírus-, ill. spamszűrő modulokat használjon az MPP, és azt is, hogy milyen sorrendben. A működés a következő. Ha az első spamszűrő modul spamként azonosítja a levelet, akkor készen vagyunk. Ha nem, akkor átadja a sorban következőnek. Ha az spamként azonosítja, akkor készen vagyunk, ha nem, akkor megyünk a következő spamszűrő motorra, és így tovább. Az antivírus szoftverek esetében hasonlóképpen jár el az MPP. Tehát az egyes motorok sorban egymás után következnek, ami a logfile-ból is látható, és nem párhuzamosan egyszerre kapják meg a levelet.
Ez azért lényeges, mert a korábbi, az MPP ‘majdnem olyan gyors, mint a clapf’, következtetésünk csak akkor igaz, ha csak gyors spamszűrő motorokat használunk, és ha a levelek zöme spam, amelyek nagy részét már az első helyen álló spamszűrő is felismeri.
Azonban a spam ill. a jó levelek aránya manapság kb. fele-fele, és ez azzal jár, hogy a levelek ~50%-a esetében az összes spamszűrőn végigmegy a levél. Ha az ingyenesen elérhető SpamAssassin is a spamszűrő motorok között van, akkor ez katasztrofális hatással lesz a teljesítményre, vö. az Általában amavis/maia/spamassassin kombinációkra gondolok open source alatt. állítással, ill. az fentebb említett ezekhez képest 10-100x teljesítmény növekedéssel.
A végső konklúzió
Az nem vitás, hogy az MPP magasan veri a SpamAssassin-t (hacsak nincs bekapcsolva az SpamAssassin az MPP-ben), de a végső konklúzió mégis az, amit Zdziarski is mond:
Azaz: a kereskedelmi spamszűrők biztosan nem skálázódnak jobban az open source termékeknél. Sok nyílt forrású termék szolgál ki több százezenyi felhasználóval rendelkező rendszereket – semmi sem támasztja alá, hogy egy kereskedelmi termék jobban teljesítene.
Leave a Reply