Hardware and performance

Hi Sergio,

Thanks for raising the question. I suspect it's one that others have encountered too.

Firstly I think we need to collect some more information.

When Moodle sends mails from the forum there are many different stages.

1. Obviously the first step is a user posting the forum post. This doesn't actually send anything immediately.
   
2. Typically there is a 30 minute wait after that before the post is considered for sending. This can be skipped by some users.
   
3. There is a scheduled task, which is called by the system cron which then picks up and processes all awaiting messages. It sends them to the Mail Transfer Agent (MTA).
4. The MTA receives all messages and then processes the sending of them.

You can have delays at steps 3, and 4, as well as the likely standard 30 minute wait.

So firstly you need to check your configuration. How often are you running cron. How often is the forum scheduled task scheduled to run? You can check this in Site administration -> Server -> Scheduled tasks -> Forum mailings and maintenance jobs. Check to see how often this is run. The default value is "* * * * *" which means it will run every minute.

You also have to look at how your Moodle cron is actually called. An outside process has to call the cron process within Moodle. In Linux-type environments you'll typically see this in crontab, or cron.d. You can read about how that happens at https://docs.moodle.org/34/en/Cron.

It's quite common to see cron configured to only run every hour or something on older sites, or where the server admin is not the Moodle admin. We would recommend running this much more regularly - for example once a minute. Also, if this is an older installation, then you may find that there is external locking and the Moodle cron is actually only called occasionally. The conversation looks like: The server attempts to get a lock and succeeds - it now calls the Moodle cron; 5 minutes later the server tries to get the lock again but the previous run hasn't finished, so it cancels; repeat for 2 hours; the original Moodle cron run finishes and the lock is released; the server attempts to get a lock and succeeds - it now runs the Moodle cron. That older locking can now be removed as Moodle locks its own cron.

The next steps location to check is the MTA. This is the most likely cause of the delay and it is well beyond the scope of Moodle.

You can configure Moodle to send mail via SMTP, or via Sendmail. Depending on how you host your server (Windows vs. Linux for example) will depend on how you set this. Personally I have always run my own MTA on all Moodle servers which handle queueing and processing of all e-mail. When I worked for a University, these MTAs (we ran Exim) queued the e-mail and passed it to the University's mail server for sending.

A lot of things can go wrong at that stage. One of the most common things I've seen is that people configure their MTA to take as much e-mail as you can throw at it. The problem with this is that the MTA is now trying to send all of that, as quickly as possible, and it ends up exhausting its resources and taking more time. Often it is better to have it queue more mail and process less of it at once. Either way, this is likely an issue for your systems people.

10,000 e-mails really isn't that many and I would not expect a two hour delay. It does suggest some form of mis-configuration.

Hope this helps you in tracking this issue down,

Andrew