mathias.bedu@epitech.eu writes:
I am currently trying to optimize my mailman installation, which is working. The only issue is that i see that mailman seems to process a few number of messages (around 50 each times), then stopping, and then processing few next messages.
What makes you think that this is Mailman stopping?
Mailman's default behavior is to send messages to the MTA as fast as it will accept them, and let the MTA take care of any throttling or optimization. Mailman even tries to parallelize this process. So if you're seeing delays I believe that is more likely to be the MTA delaying acceptance rather than Mailman. The other possibility is lists that have DMARC mitigation on only for p=reject domains. Then there may be delays due to DNS lookups to check for the From domain's DMARC policy.
I precise that the machine itself is largely more powerful than what mailman is using.
This is probably true, but CPU and memory are not usually what limits mail delivery. Aside from MTA and DNS delays, and very underpowered hosts, there's no reason why Mailman would be be stopping for more than a second or two even if some of the "be nice to the MTA" parameters below are given restrictive values.
So my question is : could you give me some leads for potentials parameters or stuff like this that i could modify to optimize the installation ?
You might look at these parameters in your configuration file, or in the definition file schema.cfg (do not change this file because it is overwritten by upgrades). The defaults are set pretty much as fast as possible.
# Ceiling on the number of recipients that can be specified in a single SMTP # transaction. Set to 0 to submit the entire recipient list in one # transaction. max_recipients: 500
# Ceiling on the number of SMTP sessions to perform on a single socket # connection. Some MTAs have limits. Set this to 0 to do as many as we like # (i.e. your MTA has no limits). Set this to some number great than 0 and # Mailman will close the SMTP connection and re-open it after this number of # consecutive sessions. max_sessions_per_connection: 0
# Maximum number of simultaneous subthreads that will be used for SMTP # delivery. After the recipients list is chunked according to max_recipients, # each chunk is handed off to the SMTP server by a separate such thread. If # your Python interpreter was not built for threads, this feature is disabled. # You can explicitly disable it in all cases by setting max_delivery_threads # to 0. max_delivery_threads: 0