Jose,

I'd like to see this included.  It's a smart change.  Would you be
willing to update it to the current git tree, and maybe look at
Hanno's comments?

The one thing that concerns me is this forces a write to disk in cases
where it might not otherwise happen.  (Realistically, most qpsmtpd
cases are going to write to disk for some plugin or another... but
some might not.)  What about using IO::String to get the fh, instead
of one on disk?

-R

Jose Luis Martinez wrote:
> 
> El 19/04/2010 12:54, Dale Gallagher escribió:
> > Hi all
> >
> > Any reason why I should not be using the maildir plugin, instead of
> > the qmail-queue plugin, other than for the .qmail flexibility in
> > delivery? I'd like to improve performance and it seems somewhat of a
> > waste for qpsmtpd to spool messages and then hand it over to
> > qmail-queue to spool again....
> 
> Because qmail-queue will be able to then forward to qmail-remote for
> non-local domains (relay) in f(x) of your qmail configuration. Maybe
> the retries that the qmail queue does are of interest too (consider
> your DSPAM out of service)... Maybe the additional qmail-local
> concurrency control is of help too...
> 
> I patched qmail-queue plugin to make it more efficient (consume lots
> less CPU). I sent it to the list some time ago, but after Hanno's
> suggestions, I didn't follow
> up. 
> http://markmail.org/message/l3zufmxgbwyblse4#query:+page:1+mid:7rcwalhbupyrjc44+state:results
> 
> Attached is the modified plugin considering the body_fh being undef.
> I've been using it in production happily for quite some time now
> without problems.
> 
> Any feedback is more than welcome ;) (specially if you find more
> efficient block sizes... I really couldn't get around to benchmarking
> that).
> 
> Jose Luis Martinez
> jlmarti...@capside.com
> 

Reply via email to