用于django app的uWSGI nginx避免了pylibmc多线程并发问题?
介绍 本周我遇到了这个非常有趣的问题,最好从一些事实开始: > pylibmc是not thread safe,当用作django memcached后端时,直接在shell中启动多个django实例会在遇到并发请求时崩溃. 精 从第一个事实开始,这是我重现pylibmc问题的方式: pylibmc的失败 我有一个django应用程序,它执行了很多memcached读取和写入,并且有这个部署策略,我在shell中启动多个django进程,绑定到不同的端口(8001,8002),并使用nginx来进行平衡. 我使用locust对这两个django实例启动了两个单独的负载测试,这就是: 在上面的屏幕截图中,他们都崩溃并报告完全相同的问题,如下所示:
uWSGI来救援 所以在上面的例子中,我们了解到通过pylibmc对memcached的多线程并发请求可能会引起问题,这在某种程度上不会打扰具有多个工作进程的uWSGI. 为了证明这一点,我使用以下设置启动uWSGI:
这告诉uWSGI启动两个工作进程,然后告诉nginx服务器任何django静态文件,并将非静态请求路由到uWSGI,看看会发生什么.在服务器启动的情况下,我在localhost中对django启动了相同的蝗虫测试,并确保每秒有足够的请求来引发对memcached的并发请求,结果如下: 在uWSGI控制台中,没有死工作进程的迹象,并且没有工作人员重新生成,但是查看屏幕截图的上半部分,确实存在并发请求(5.6 req / s). 这个问题 我非常好奇uWSGI如何让它消失,而我无法从他们的文档中了解到,回顾一下,问题是: uWSGI是如何管理工作进程的,因此多线程memcached请求不会导致django崩溃? 事实上,我甚至不确定这是uWSGI管理工作流程以避免这个问题的方式,还是uWSGI附带的其他一些魔术,我在他们的文档中看到了一些名为memcached路由器的东西,我没有’很明白,这有关系吗? 最佳答案
是不是因为你实际上有两个由uWSGI管理的独立进程?当您设置processes选项而不是workers选项时,所以您实际上应该有多个uWSGI进程(由于您使用的配置,我假设主要有两个工作程序).每个进程都有自己加载的pylibmc,因此线程之间没有状态共享(毕竟你还没有在uWSGI上配置线程).
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |