2009.01.09.
clapf code refactoring
Az utóbbi napokban nem új feature-ket adtam a spamszűrőhöz, hanem átdolgoztam néhány részletet. Arra kerestem ötletet, hogyan lehetne a MySQL lekérdezéseket gyorsítani. Eddig ugyanis azt a nem túl eredeti ötletet követtem, hogy a tokenek listáján végigmentem, majd elsütöttem egy selectet. 2k token esetén ezt 2k selectet eredményezett, ami azért – hiába gyors a MySQL – eltartott pár száz millisecundumig.
Mostmár azonban egy SELECT … WHERE token IN (…) jellegű SQL utasítást építek fel, és egy menetben kérdezem le az összes tokent. Ez 7-8x-os sebességnövekedést jelent, azaz a clapf ennyivel kevesebb ideig gondolkozik, hogy egy adott levél az ham vagy spam.
Összedobtam egy VMware virtuális masinát, és ráeresztettem 3159 levelet (2002 spam, 1157 ham levél) egy olyan felhasználóra, aki egy alias a /dev/null-ra. Az eddigi verziónak átlag ~800 ms-ba telt, amíg végzett egy levéllel, most azonban átlag ~110 ms alatt dönteni tudott egy levélről. A leveleket szekvenciálisan küldtem SMTP-vel a teszt gépre, ami nem jelenti azt, hogy a clapf egyszerre csak egy levéllel foglalkozott. A postfix ugyanis párhuzamosan, több levelet engedett a clapf spamszűrőre, amely így átlag 5 levél/sec teljesítményt ért el.
Ez nem tűnik túl soknak, de ez a teszt nem arra ment ki, hogy minél nagyobb áteresztőképességet érjek el (erre amúgy sem egy virtuális gép a legmegfelelőbb terep), hanem hogy növeljem a program teljesítményét. 800 ms helyett ~110 ms elég jó teljesítmény.
A korábbi postban említett cache démonról még nem mondtam le, majd visszatérek még rá. Eközben alapos módosításokat végeztem szinte minden .c és .h fájlban. A leggyakrabban használt függvényekben az adat struktúrákra mutatóval hivatkozom, ami még gyorsít egy kicsit, mert nem kell memóriaterület másolni.
Szóval ezek kerültek be a 0.4.0-rc2-be. Elvileg minden (eddigi) funkció rendben működik. Ha nem jön elő bug a következő hetekben, akkor jó lesz a végleges 0.4.0-nak is.
