Patrik Rak:
> On Thu, 25 Jun 2020, Patrik Rak wrote:
>
> > But that's what confuses me even further because separate
> > per-mail-recipient-count classes don't help with that, do they? (If all
> > you get in your system is single recipient mail, this type of classes
> > doesn't change a thing.)
>
> Ahh, I see now. I misread your classes description, and I thought the
> mails will be assigned to the classes based on the number of recipients.
> But it seems you were talking about dynamic number of all pending
> deliveries, across all mails from that sender. Which would include
> shuffling the mails between the classes back and forth based on those
> numbers change, right?
Once a delivery request is assigned a class, that assignment is
permanent. It's not worth the trouble to reassign a request to a
class: each class threshold is >10x higher, so we would get only a
<10% improvement for a lot of added complexity.
> Hmm, thinking about that, still most of what I wrote holds true, I think...
I'll read that after responding.
> > But if that's really the case (the single sender usurping everything), why
> > complicate things? Rather than dealing with that during the outbound
> > selection, I'd say cut it during the inbound phase. Don't even let it into
> > the system. Simply don't pickup mail from sender who already has too many
> > recipients in in-memory queue during the active queue scan. It prevents it
> > from clogging the queue or even the agents (depending on the limit), is
> > trivial to do, and requires no change to the scheduling algorithm itself.
That's effectively deferring the 'excess' deliveries, otherwise the
scheduler would keep running into the same queue file over and over
again and and stop making progress. I don't like designs that do
that.
Wietse
> The limit could even be dynamic, based on the number of deliveries
> in-core divided by number of senders in-core. With single sender, he can
> have it all. With another sender appearing, his budget is cut in half. If
> there are thousands of senders, each gets just a tiny proportion of the
> in-memory queue.
>
> Patrik
>
