[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qmail
Subject:    Re: Patch to speed up qmail-remote
From:       Erwin Hoffmann <feh () fehcom ! de>
Date:       2005-08-31 19:42:03
Message-ID: 3.0.6.32.20050831214203.013a2268 () orion ! fehnet ! de
[Download RAW message or body]

At 09:37 30.08.2005 +0800, Feizhou wrote:
>
>> qmail-remote becomes a bottleneck (and a heavy load for qmail-send) if it
>> tries to deliver (ever and ever) i.e. Spam emails to none-existing
>> accounts/reply-addresses. Avoid those bounces in the first place (e.g. by
>> means of my RECIPIENTS extension).
>
>That's hardly qmail-remote's fault that it has to try to deliver to 
>slow/unresponsive destinations. It is more like that the limited number 
>of delivery slots available that holds up mail to fast/responsive 
>destinations because all/most of the remote delivery slots have been 
>taken up by deliveries to the slow destinations. This is where 
>big-concurrency helps...and at the same time makes the box a possible 
>source of a DOS effect on the remote destination(s).

Hm. I hardly get your point. 

(1) You can easly restrict the number or qmail-remote parallel deliveries.


>> 
>> From my figures, all those patches (i.e. bigtodo, ext-bigtodo) are
>> meaningless if you avoid unnecessary (remote & local) deliveries. The ratio
>> of useless SMTP connections to useful might be as high as 10 to to
>> dictionary spam.
>
>When you are doing around 1000 local deliveries per minute those patches 
>you are dissing are the only thing that prevents you from building a 
>large queue of deliverable emails. 

(2) Deliveriable mails to existing accounts or any ? 

>Now that filesystems with indexed 
>directory support are more common in Linux space, the big-todo and 
>therefore the big-ext-todo combination may not be so useful anymore but 
>the ext-todo patch definitely makes a difference.

(3) Maybe it does a better "arbitering" of local deliveries. BTW: This
effect can be seen *lowering" the number of local deliveries instead of
raising them.
>> 
>> @Bruce: Show figures. Use realistic test-cases.
>
>What is realistic for you may not be for others. If he wants to make 
>qmail-remote all the more efficient then I say please do.

I appreciate his approach. But without knowing the "boundary conditions" we
hardly know, whether we tune the "write knobs". 

Anyway, I'll have a look at this code.

@Bruce: Thank you.

regards.
--eh.

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/
Wiener Weg 8, 50858 Cologne | T: +49 221 484 4923 | F: ...24
[prev in list] [next in list] [prev in thread] [next in thread]