Django/WSGI应用程序中的持久数据库连接 [英] Persistent DB Connection in Django/WSGI application

查看:59
本文介绍了Django/WSGI应用程序中的持久数据库连接的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我希望在django驱动的Web应用程序中保持与第三方旧数据库的持久连接打开.

I want to keep a persistent connection open to a third party legacy database in a django powered web application.

我想保持Web应用程序与旧数据库之间的连接处于打开状态,因为对于这个特殊的数据库,创建新连接非常慢.

I want to keep the a connection between the web app and the legacy database open since creating a new connection is very slow for this special DB.

这与通常的连接池不同,因为我需要存储每个Web用户的连接.用户"Foo"需要在Web服务器和旧版数据库之间建立自己的连接.

It is not like usual connection pooling since I need to store the connection per web user. User "Foo" needs its own connection between web server and legacy DB.

到目前为止,我使用Apache和wsgi,但是如果其他解决方案更合适,我可以更改.

Up to now I use Apache and wsgi, but I could change if an other solution fits better.

到目前为止,我使用django.在这里我也可以改变.但是痛苦会更大,因为已经有很多代码需要再次集成.

Up to now I use django. Here I could change, too. But the pain would be bigger since there is already a lot of code which needs to be integrated again.

到目前为止,我使用Python.我猜想Node.js更适合这里,但是更改的痛苦太高了.

Up to now I use Python. I guess Node.js would fit better here, but the pain to change is too high.

当然需要某种超时.如果N分钟内没有来自用户"Foo"的http请求,则需要关闭持久连接.

Of course some kind of timeout would be needed. If there is not http-request from user "Foo" for N minutes, then the persistent connection would need to get shut down.

如何解决?

更新

我称它为 DB ,但它不是通过settings.DATABASES配置的DB.我需要集成一个奇怪的,遗留的,没有广泛传播的类似DB的系统.

I call it DB but it is not a DB which is configured via settings.DATABASES. It is a strange, legacy not wide spread DB-like system I need to integrate.

如果此时我有50个人在使用Web应用程序在线,那么我需要保持50个持久连接.每个用户一个.

If I there are 50 people online using the web app in this moment, then I need to have 50 persistent connections. One for each user.

连接到数据库的代码

我可以在每个请求中执行此行:

I could execute this line in every request:

strangedb_connection = strangedb.connect(request.user.username)

但是此操作很慢.使用连接速度很快.

But this operation is slow. Using the connection is fast.

当然, strangedb_connection 不能序列化,也不能存储在会话中:-)

Of course the strangedb_connection can't be serialized and can't be stored in a session :-)

推荐答案

工作程序守护程序管理连接

您的图片当前如下所示:

worker daemon managing the connection

Your picture currently looks like:

user  ----------->  webserver  <--------[1]-->  3rd party DB

connection [1] is expensive.

您可以使用以下方法解决此问题:

You could solve this with:

user ---->  webserver  <--->  task queue[1]  <--->  worker daemon  <--[2]-> 3rd party DB

[1] task queue can be redis, celery or rabbitmq.
[2] worker daemon keeps connection open.

辅助守护程序将与第三方数据库建立连接并保持连接打开.这意味着每个请求都不必支付连接费用.任务队列将是进程间通信,将工作分派到守护程序并在第3方数据库中进行查询.Web服务器在处理方面应尽可能轻巧,并允许工作人员执行昂贵的任务.

A worker daemon would do the connection to the 3rd party database and keep the connection open. This would mean that each request would not have to pay the connection costs. The task queue would be the inter-process communication, dispatching work to the daemon and do the queries in the 3rd party db. The webserver should be as light as possible in terms of processing and let workers do expensive tasks.

实际上,您可以 preload 并在第一个请求之前进行昂贵的连接.这是通过 WSGIImportScript 配置指令完成的.我不记得是否有预加载+分叉配置,这意味着每个请求都已经打开并共享了连接.但是由于您拥有大部分代码,因此这可能是一个简单的实验.

You can actually preload and have the expensive connection done before the first request. This is done with the WSGIImportScript configuration directive. I don't remember at the top of my head if having a pre-load + forking configuration means each request will already have the connection opened and share it; but since you have most of the code, this could be an easy experiment.

uwsgi 也支持预加载.这是通过 import 指令完成的.

uwsgi supports preloading too. This is done with the import directive.

这篇关于Django/WSGI应用程序中的持久数据库连接的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆