I have a django site. Certain actions by the end user send email to the rest of users in a group.
我有一个django网站。最终用户的某些操作会向组中的其他用户发送电子邮件。
When the number of users gets to be > 20 it can add 1-3 seconds to the request cycle, which I don't like. I'd like to be able to send the email from a non-blocking function.
当用户数量> 20时,它可以在请求周期中增加1-3秒,这是我不喜欢的。我希望能够从非阻止功能发送电子邮件。
I know RabbitMQ and Celery in conjunction can solve this, but with 200 users that seems like over-engineering and it adds two more applications I have to install, understand, and babysit.
我知道RabbitMQ和Celery可以解决这个问题,但有200个用户似乎过度工程,它增加了两个我必须安装,理解和保姆的应用程序。
I've done some research, and it appears that both threading.Thread and subprocess would be ways to wrap a non-blocking call. Am I missing an obvious way to do this? Are there downsides to using either the threading.thread or subprocess approach?
我做了一些研究,看起来两个线程都是。线程和子进程是包装非阻塞调用的方法。我错过了一个明显的方法吗?使用threading.thread或subprocess方法有缺点吗?
Thanks, Ted
3 个解决方案
#1
9
Offloading the work to some other external process is really the right thing to do, and once you've done it, it's not likely to be the last time you do it. Celery/RabbitMQ is a decent solution, and the nice thing is they're already there. Recent RabbitMQ releases have a decent web-based management app and a decent management API that'll make babysitting pretty easy, and celery works pretty well in Django apps.
将工作卸载到其他外部进程是非常正确的事情,一旦完成,它可能不是你最后一次这样做。 Celery / RabbitMQ是一个不错的解决方案,好消息是它们已经存在。最近的RabbitMQ版本有一个不错的基于网络的管理应用程序和一个体面的管理API,这将使保姆非常容易,芹菜在Django应用程序中工作得很好。
You can do this with subprocess or threading, but to be honest, I think that's a bad habit to get into. Unfortunately, they're the most straightforward ways to do what you want to do if you don't want to offload things.
你可以用子进程或线程来做到这一点,但说实话,我认为这是一个不好的习惯。不幸的是,如果你不想卸载东西,它们是你做你想做的最简单的方法。
If you wanted to go completely 'ghetto async email' you could have your app just dump emails to files in a directory and have a cron job check the directory for files in that directory every minute, and send them off as emails, but really that's a lot more work than rabbit/celery.
如果你想完全去“ghetto异步电子邮件”你可以让你的应用程序只是将电子邮件转发到目录中的文件并让cron作业每分钟检查该目录中的文件目录,然后将其作为电子邮件发送出去,但实际上就是比兔子/芹菜还要多得多。
I say just go with rabbit/celery. It's not as much work as it seems, and it's worth it going forward.
我说跟兔子/芹菜一起去吧。这不像看起来那么多,并且它值得继续前进。
#2
0
You have long-since solved this problem, but I just had the exact same problem, and this was the quickest way forward to the 'ghetto async email' you mentioned:
你很久以来就解决了这个问题,但我遇到了同样的问题,这是你提到的'ghetto async email'的最快捷方式:
http://djangosnippets.org/snippets/1864/
I added a monkeypatch, described here, to get rid of the threading exception:
我添加了一个monkeypatch,在这里描述,以摆脱线程异常:
import threading
threading._DummyThread._Thread__stop = lambda x: 42
And now Bob is, as they say, my uncle.
现在鲍勃,正如他们所说,是我的叔叔。
#3
0
Much simpler than offloading to celery, you can always try the (included in django) Signals module, sounds like just what you need.
比卸载到芹菜更简单,你可以随时尝试(包括在django中)信号模块,听起来就像你需要的。
#1
9
Offloading the work to some other external process is really the right thing to do, and once you've done it, it's not likely to be the last time you do it. Celery/RabbitMQ is a decent solution, and the nice thing is they're already there. Recent RabbitMQ releases have a decent web-based management app and a decent management API that'll make babysitting pretty easy, and celery works pretty well in Django apps.
将工作卸载到其他外部进程是非常正确的事情,一旦完成,它可能不是你最后一次这样做。 Celery / RabbitMQ是一个不错的解决方案,好消息是它们已经存在。最近的RabbitMQ版本有一个不错的基于网络的管理应用程序和一个体面的管理API,这将使保姆非常容易,芹菜在Django应用程序中工作得很好。
You can do this with subprocess or threading, but to be honest, I think that's a bad habit to get into. Unfortunately, they're the most straightforward ways to do what you want to do if you don't want to offload things.
你可以用子进程或线程来做到这一点,但说实话,我认为这是一个不好的习惯。不幸的是,如果你不想卸载东西,它们是你做你想做的最简单的方法。
If you wanted to go completely 'ghetto async email' you could have your app just dump emails to files in a directory and have a cron job check the directory for files in that directory every minute, and send them off as emails, but really that's a lot more work than rabbit/celery.
如果你想完全去“ghetto异步电子邮件”你可以让你的应用程序只是将电子邮件转发到目录中的文件并让cron作业每分钟检查该目录中的文件目录,然后将其作为电子邮件发送出去,但实际上就是比兔子/芹菜还要多得多。
I say just go with rabbit/celery. It's not as much work as it seems, and it's worth it going forward.
我说跟兔子/芹菜一起去吧。这不像看起来那么多,并且它值得继续前进。
#2
0
You have long-since solved this problem, but I just had the exact same problem, and this was the quickest way forward to the 'ghetto async email' you mentioned:
你很久以来就解决了这个问题,但我遇到了同样的问题,这是你提到的'ghetto async email'的最快捷方式:
http://djangosnippets.org/snippets/1864/
I added a monkeypatch, described here, to get rid of the threading exception:
我添加了一个monkeypatch,在这里描述,以摆脱线程异常:
import threading
threading._DummyThread._Thread__stop = lambda x: 42
And now Bob is, as they say, my uncle.
现在鲍勃,正如他们所说,是我的叔叔。
#3
0
Much simpler than offloading to celery, you can always try the (included in django) Signals module, sounds like just what you need.
比卸载到芹菜更简单,你可以随时尝试(包括在django中)信号模块,听起来就像你需要的。