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? Hmm, thinking about that, still most of what I wrote holds true, I think... > 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. 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
