Forecast for the next deploy?

[GabrielNexT]

Hi, I would like to use the runmailer command, which will send emails without the need for a cron.
Do you have any forecast for deploying on pip?

[spookylukey]

You can always pip install from a git repo - https://adamj.eu/tech/2019/03/11/pip-install-from-a-git-repository/

[spookylukey]

Re-opening until I address this.

Current blockers:

• Fix issue with BigAutoField  #152

[GabrielNexT]

Spooky, I have a problem at the company I work for, a momentary delay in sending some emails, have you ever had a similar problem? It happened on an old project, I suspect that the email queue got too big and the mailer couldn't send them all quickly.

Testing the app, I noticed that it doesn't really send emails very quickly and looking at the code, I got to the function

django-mailer/src/mailer/engine.py

Line 184 in 035b518

def send_all():

I'm not a python master but it seems to me that this function is sequential, wouldn't it be better to parallel it?

I'm thinking of a solution and maybe do a PR.

[spookylukey]

Sending emails will take time, because the data has to go over the network. How long was the delay, how many emails were there and how big were they?

Sending them in parallel may make things faster, but if you try to do too many in parallel almost certainly you will cause problems and could actually make things go slower, because of network congestion and the way the server might respond. In some cases, you could get throttling errors (e.g. if you backend was an HTTP API, which many people are using now).

So, overall, the change might not be worth it. We should also not that doing it in parallel will require multiple process or multiple threads, which can be a very tricky thing in this context, and would introduce a significant amount of fragility.

[GabrielNexT]

I don't know exactly how many emails were in the queue, but in some cases it took a few minutes to send the emails.
We currently use Sendgrid SMTP.

Thanks for the explanations.
All my doubts were resolved, whenever you want, you can close the issue.

[syre]

Now that #152 is merged, perhaps a new release can be made?

[spookylukey]

2.2 has been released now.