Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forecast for the next deploy? #150

Closed
GabrielNexT opened this issue Sep 23, 2021 · 7 comments
Closed

Forecast for the next deploy? #150

GabrielNexT opened this issue Sep 23, 2021 · 7 comments
Labels

Comments

@GabrielNexT
Copy link

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
Copy link
Contributor

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

@spookylukey
Copy link
Contributor

Re-opening until I address this.

Current blockers:

@GabrielNexT
Copy link
Author

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

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
Copy link
Contributor

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
Copy link
Author

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
Copy link

syre commented Feb 15, 2022

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

@spookylukey
Copy link
Contributor

2.2 has been released now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants