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.
