2009.12.23.
Hány licence kell neked???
A spamblog PR cikkei között olvastam egy érdekes írást Virus Bulletin: a spamszűrők együtt jobbak címmel, amiben a egy érdekes elmélet szerepel:
“A Virus Bulletin kb. 200.000 valódi email felhasználásával 14 gyártó termékét tesztelte párhuzamosan, az egyes spamszűrők válogatták külön a levelezést levélszemétre és jó levelekre. [...] 4 megoldás is volt, ami egyetlen jó levelet sem jelölt meg, ugyanakkor a szűrési pontosságuk hagyott még kívánni valót maguk után. [...] ha elméletben megvalósítanának egy olyan szűrőt, ami mind a 14 tesztelt megoldást tartalmazza, de csak akkor jelöl meg egy levelet spamnek, ha legalább 5 termék szerint az, akkor egy lényegesen jobb szűrőt kaphatnának.
Az elméletben felállított többmotoros szűrő így 99.89%-os pontossággal azonosítaná a levélszemetet (ami minden termék eredményénél jobb), míg továbbra sem jelölne meg egyetlen jó levelet sem.”
A Virus Bulletin teóriája helytálló, de egy apróságról azért jó, ha tudunk. Ha minden levelet 14 szűrőn vezetünk át (vagy amíg legalább 5 szűrő nem sikít, hogy spam), az drasztikusan megnöveli a rendszer költségét.
A szükséges teljesítményigény (processzor, memória, i/o, …) (átlag) 14x-esére nő, vagy ha jobban tetszik, a rendszer áteresztőképessége az 1/14-édre csökken. És ha mindez nem lenne elég, akkor – mivel kereskedelmi termékekről van szó – 14 db termék licencét kell megvenni, frissíteni, stb.
Tehát az a termék, amely 14 kereskedelmi megoldást aggregál, az (átlagosan) 14x többe kerül, és a teljesítménye (átlagosan) 1/14-e annak, mintha csak 1 termékre bíztuk volna a spamszűrést. A hivatkozott PR-cikkben szó van az MPP termékről, amely 3-10 antispam megoldást képes kombinálni. Kész szerencse, hogy az MPP esetén legrosszabb esetben is csak egy 10-es szorzóval ill. osztóval kell számolni.
Azonban spamet szűrni nem csak kereskedelmi termékekkel lehet. Jonathan Zdziarski a Justifying Statistical Filtering (and Open Source Technology) című írásában megjegyzi, hogy “Well-written open-source filters have achieved rates of 99.5% to 99.9% and beyond with little effort.”, azaz szabad fordításban: a jól megírt nyílt forrású [spam]szűrők könnyedén elérik a 99.5-99.9%-os pontosságot, vagy még jobbat.
Ha tehát extrém pontosságra van szükség, akkor a) veszünk egy terméket, ami valójában akár 10-15 termék összegyúrva, vagy b) keresünk egy nyílt forrású, statisztikai szűrőt, ami egymaga képes az előbbi produkcióra.
December 25th, 2009 at 4:53:08
Vagy c)
Fogunk par olyan nyilt forrasu szurot, ami egymaga is kepes lenne erre, es osszegyurjuk egyetlen szurove, lekorozve igy az a) es b) megoldast pontossagban (es sajnos CPU hasznalatban is).
vagy d)
Megnezzuk, hogy melyik nyilt forrasu szuro mit csinal, es a legjobb otleteket es algoritmusokat osszeszedve csinalunk egy ujat. Igy kozos DB-t hasznalhatnak, es az eroforrasigenye sem no meg annyira.
December 25th, 2009 at 9:53:22
A c) nem tűnik (sokkal) jobbnak az a)-nál. Viszont a d) tetszik (bár nem látom a különbséget a b)-től).
Ha van 1-2 jó ötleted/algoritmusod, akkor ne tartsd titokban
January 6th, 2010 at 15:55:19
Az elmélet és a gyakorlat szinte mindenben eltér, ahogy az MPP esetében is ez teljesen igaz. Például 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. Ugyanis a gyakorlatban teljesen máshogy teljesít egy párhuzamos nagy sebességű feldolgozásra optimalizált bináris kód és egy percenként frissített adatbázis, mint ahogy az az elméletben hangzik, főleg ahogy az a VB leírja. A valóság teljesen más, tessék kipróbálni, segítünk szívesen.
January 6th, 2010 at 16:18:59
Hát, ha valódi az a 10-100x teljesítmény különbség, akkor valami nagyon rossz open source termékről lehetett szó. Lehet tudni, hogy melyikről/melyekről van szó?
De üsse kavics, fogok egy (virtuális) masinát, aztán összedobok egy benchmark-ot.
January 6th, 2010 at 18:18:07
Általában amavis/maia/spamassassin kombinációkra gondolok open source alatt.
Gyorsan utánakérdeztem, egy tesztet találtam, amit anno az IBM-mel készítettünk régebben. Ez ugyan egy stabilitás teszt, de a végeredmény:
4. Test Scenario:
Send messages to 100 users, 10 messages per connection . The message is test.msg included in mpp kit.
Delay between launching another connection 1.5 seconds.
1. Amavis wih clamascan as scanner — unacceptable .. Sendmail get killed
2. Amavis with clamd as scanner: .. 25 messages were not accepted because the server was overloaded
– no warning messages
– time: 2m31.684s
3. MPP with ClamAV as scanner:
3.1. timeout between connections 1.5 seconds
– processing_threads = 5
– virus_scaner = clamav
– no warning messages
– time: 2m33.361s
3.2. timeout between connections 0.5 seconds
– processing_threads = 5
– virus_scaner = clamav
– no warning messages
– time: 0m51.231s
A lényege az, hogy az amavisszal összehasonlítva az MPP nem hogy nem halt meg, de sokkal nagyobb terhelést is elbírt, amikor 1,5 mp-ről 0,5 mp-re csökkentették a kapcsolatok közötti késleltetést.
Ráakadtam egy másik, teljesen friss telepítésre is: “Went from 6x smtp servers running maia+amavisd+sa (and these were struggling) to 2x mppd. One would do it but we run 2 for high availability.”, itt is látszik, hogy 6 szervert tudtak 1-el kényelmesen helyettesíteni (2-vel lett HA).
Érdemes talán a Cloudmarknál utána kérdezni a benchmarkoknak, azt hiszem ők büszkék rá, hogy akár 100x-os terhelést is elbír egy Cloudmark alapú rendszer.
A tesztelés pedig nem egy egyszerű kérdés, hiszen az MPP nem egy spamszűrő, hanem archiváló, levélfeldolgozó, webservice/RSS gyártó, SQL motorokat alkalmazó, programozható, CMS/ERP rendszerhez integrálható platform… simán spamszűrési sebesség mérésére tényleg csak egyszerűen egy Cloudmarkot javasolnék.
January 6th, 2010 at 20:21:27
Kaptam még egy tonna MPP tesztet, szerepel benne terhelési modell, pontos specifikációk, rengeteg eredmény. Van köztük Cloudmark szűrés 88.25 levél/mp sebességgel (egyszerű levéleldobás), de MySQL alapú karanténnal, LDAP-ból töltött felhasználói beállításokkal is 36.77 levél/mp-et produkál. Ha írsz nekem egy email az itt megadott címemre, akkor szívesen átküldöm. Az biztos, hogy nem lesz egyszerű egy ilyen tesztet megalkotni
January 6th, 2010 at 22:15:27
“Általában amavis/maia/spamassassin kombinációkra gondolok open source alatt.”
Hát, azért az MPP nem tette magasra a lécet azzal, hogy a spamassassin-nal és barátaival méri össze az erejét.
Azonban engem nem a Cloudmark hivatalos benchmark eredmények érdekelnek (szeretek magam tesztelni, és a saját szememnek hinni), mert úgy szólt a tétel, hogy az MPP még úgy is (sokkal) gyorsabb, hogy több motort használ.
Ezt azonban egy olyan teszttel kellene bizonyítani, amiben az MPP minden spam- ill. víruszűrő modulja dolgozik. Tehát az nem ér, hogy ‘ha sebességre gyúrsz, akkor próbáld ki a Cloudmark-ot’.
A tesztet egyébként úgy végeztem, hogy minden – a teljesítményteszt szempontjából – felesleges funkciót (pl. archiválás, …) kikapcsoltam volna az MPP appliance-ban, hogy ne fogják feleslegesen az erőforrásokat, és hogy csak a levélfeldolgozás és -továbbítás működjön, hogy az így a kapott eredmény összevethető legyen egy ‘opensource megoldással’.
És ha már a licence-ek is szóba kerültek, hadd említsek meg egy otromba hibát, ami elveszi az ember kedvét a licencekkel szórakozástól.
A letöltött vmware appliance-ban (v3.3) már a letöltés (=ma) előtt régen lejárt az installált trial licence, úgyhogy el sem indul az mpp. Nagy, nagy feketepont….
January 7th, 2010 at 11:12:33
Ákos küldött ma egy trial kulcsot, így végül elindult. Játszom vele egy kicsit…
January 17th, 2010 at 16:55:36
[...] csúsztatásokkal találkoztunk már, és nyilván a Raid5 számára is világos a cél: ráhangolni az olvasót a Symantec Mail [...]