Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Florin Andrei (florinandrei.myip.org)
Date: Tue Jul 06 2010 - 15:00:14 CDT
On 07/06/2010 12:27 PM, Victor Duchovni wrote:
> If you want to deliver the same number of messages to each server,
> regardless of server performance, (message-count fairness, rather than
> concurrency fairness), and suffer high latency when a slow server starts
> to impede message flow, then turning off the cache will indeed give you
> roughly uniform message distribution:
> - *New* connections are distributed uniformly
> - There is at most one delivery per connection
> - Hence messages are distributed uniformly
> However, concurrency will not be distributed uniformly, and a slow
> server will account for most or all of the concurrency, ensuring a
> high average latency even when alternative servers are sitting idle.
That's fine. One transport is on the local network, the other is across
a data link that would have been considered "as fast as local" not too
long ago. Both servers are modern fast hardware. Both are highly
available from the p.o.v. of the machines generating the emails. Even if
one of them disappears, so what, the other will just magically take over
and at most we're not worse off than before.
The "slow" server, therefore, is not that "slow". It's just different
enough (latency, mostly) to tip over the sensitive delivery algorithm,
which seems to be fine-tuned for Internet conditions, rather than local
or near-local networks.
From what you're saying, it appears that single-threaded delivery is
unnecessary - the email "generators" will simply hit the upper
connection limit and stay near it, with newly released slots being
occupied by either one relay or the other at random. That should ensure
a "fair" distribution, I think.
> What negative symptoms are your systems exhibiting?
> What *real* problem are you trying to solve?
The real problem was described in the other big thread I started
recently: delivery to a certain big popular email provider is
exceedingly slow. We have a pretty small delivery window between the
moment the messages are created and the moment they should be available
to the users - that's not a problem with all the other providers (heck,
Gmail for instance seems to absorb emails way faster than we can send
them - this even while their anti-spam filters seem at once more fair
and more effective than the other providers').
We already did long time ago some of the stuff you indicated (the spam
feedback loop, etc.) and have started a while ago working on the rest
(whitelisting, etc.) which is supposed to get us out of the red zone.
But *meanwhile* I have to make the best out of a tricky set of
Having multiple exit points seems to improve the overall delivery speed
- this is true even right now, when distribution is skewed to the faster
server 4:1. My estimate is, a near-1:1 distribution would actually fix
our time-constraint problem even before whitelisting. So you see how
this is kind of a big incentive to get it done.