Hi Viktor, thanks for helping. I've done something very similar.
I created different named transports for specific domains and have all domains I need a special treatment to use this named transport. So since I'm using Postfix + MySQL, I have a transport table with all domains and destination transport. Its quite the same thing you're proposing. Yet, I'm still with the same problem. Its worthless to have all domains I want on a specific transport and now controlling the throughput. I don't need just a transport queue for this, I need to control the throughput for all domains that are in this transport, thats why I'm working with the connection cache timers. I've also noticed a huge delivery improvement for Hotmail and Yahoo since I've started messing things around. So in the real life, I have about 10.000 domains that are hosted in the same hosting company. This company has a rigid control of their resources. Then I got all domains we had traffic in the last 3 months, looked up for their hoisting company, had everything mapped and put them all on this named transport. Now all I need is to control the delivery for these specific destinations. Basically this is what I need to be careful about: not send more than 1.000 in 10 minutes and not having more than 20 opened connections in the same time frame. Is there anything else I can do to have a better control of my throughput? Any help would be very appreciated. Thanks in advance. Att. -- Rafael Azevedo | IAGENTE Fone: 51 3086.0262 MSN: raf...@hotmail.com Visite: www.iagente.com.br Em 07/01/2013, às 14:25, Viktor Dukhovni <postfix-us...@dukhovni.org> escreveu: > On Mon, Jan 07, 2013 at 11:34:45AM -0200, Rafael Azevedo - IAGENTE wrote: > >> This is what I'm trying to do: >> >> - I need to have only one process to this transport's queue. > > mumble_destination_concurrency_limit = 1 > >> - This queue must respect the destination's policy, so I can't >> have more than 20 opened connections in 10 minutes timeframe. Thats >> why I want to use connection cache. > > The connection cache is used automatically when there is a backlog > of mail to the destination. You are defeating the connection cache > by enforcing a rate limit of 1, which rate limits deliveries, not > connections. DO NOT set a rate limit. > >> According to my configuration, I'm having only one process for >> this transport, also limiting the sending time, holding down delivery >> process, waiting 1 second for each sent message before sending >> another one. > > Instead of setting a process limit of 1, you can just specify an > explicit nexthop for the domains whose concurrency you want to > aggregate: > > example.com mumble:example.com > example.net mumble:example.com > example.edu mumble:example.com > ... > > This should the queue manager schedule deliveries to these domains > as it will combine the queues for all the domains that use the > transport into a single queue (while using the MX records for > a suitably chosen single domain). > >> And since this transport handles only specific domains, I really >> don't have to worry about receiver policies, because they told me >> to send as much as I can using the same connection, avoiding opening >> one connection per message. > > Don't enable rate delays. Do specify a common nexthop for all domains > that share the transport. Don't mess with the connection cache timers. > > -- > Viktor.
