Brian Szymanski wrote: > Guy Hulbert wrote: >> On Fri, 2008-01-18 at 12:19 -0500, Matt Sergeant wrote: >> >>>> What kinds of things do plugins need to avoid in an asynchronous >>>> world? >>>> >>> Blocking. :-) >>> >> Could you elaborate a little on this or provide a reference (link not >> biblio). >> >> > Yes, please :-) Is it all blocking IO? What is the failure mode? > >>> What are your current plugins? >>> > > Unfortunately we have a lot of non-standard and old ones... I'm not so > worried about the greylisting and whatnot...
I'll amplify what Matt said - simple file I/O (eg: queue/file) is apparently not a problem, and will work well at very high volumes (many millions per day per server). Making those operations async will only make a marginal difference except at extremely high loads. One thing that doesn't work at _all_ under async is the TLS plugin. I have run spamd/clamd at pretty high loads (~ 1-2 million/day/server). It MOSTLY works fine, but under some circumstances it seems to "overload runaway", and it locks up (sometimes even taking the machine with it). I've not run tests with things that require network services (eg: synchronous DNS queries etc), and can well imagine that they'd likely work far worse than synchronous spamd/clamd. If and when we switch to using realtime LDAP for rcpt checking, it'll have to be async queries. In the meantime, I can get away with periodically loading a complete user directory into a hash and checking it in a hook_rcpt. We intend on running spamd/clamd on our production (1-2 million/day across 5+ servers), not the trap (I've seen it exceed 20M/day, over 5 other servers). When we deploy, if the then-current spamd/clamd don't work at production volumes, we'll make those servers run forkserver, and leave the trap servers as async. Indeed, since we have a requirement for TLS on production, and TLS doesn't yet work at _all_ under async (another of Matt's tuits), we'd _have_ to use forkserver for production anyway entirely aside from loading issues.
