On Thu, Jun 19, 2008 at 05:03:30PM +0100, Ed W wrote: > > Yes, but you are grinding your disk for those ms. When you do a write > in mysql it flushes the query cache for that table, so basically the > bayes tables never really cache well. > > I guess what was suggested is something like to write the changes out to > the DB as normal, but use memcached as the coherent read cache across > servers? The point here is that you you won't hit the DB for reads and > have very fast lookups. I guess this doesn't change the load on the > amavisd-new machine much , but it may make a huge difference on the DB > machine for heavy users...
Sounds like too much premature optimization and not a lot of thought.. Every mail will have unique set of tokens, obviously it's impossible to cache such queries since they always differ. Mysql doesn't allow query cache for Bayes anyway, since SA uses prepared statements. There is a limit on the token amount you want to have for Bayes to function properly. My DB has about 3 million (~200MB of data). Any decend server will have that fully buffered in memory! Since it's indexed, the lookups are pretty much instant. To test this, I created a sql file with 10000 queries (50 random tokens per query) exactly as SA does it, and feeded it to Mysql. My low-end 2x1Ghz Sun SPARC server sustained 400 queries per second, that makes 2.5ms per query. So another cache layer would just add complexity with little to no benefit. That is if you can identify some static enough things that are queried often, which Bayes is not. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
