让Django支持数据库长连接 可以提高不少性能

让Django支持数据库长连接 可以提高不少性能

由于换了工作,所以之前的游戏引擎暂时放下,但是不会停止的,这个项目会在我的业余时间来完成。

—————————————闷骚的分割线,下面是正文——————————————-

tornado我在之前的文章里已经有过多次介绍,在此就不详细介绍了,

详细介绍可参见:

玩蛇记-使用tornado构建高性能Web应用之一

玩蛇记-使用Tornado构建高性能Web之二-autoreload

由于官网被墙,讨论组也被墙(囧,万恶的墙)所以tornado的资料很少,官网的资料也语焉不详,所以很多童鞋对如何部署使用Tornado心里没底。所以本文的主要目的就是教会刚入门的新手如何在生产环境使用Tornado

Tornado是一个异步web框架和服务器,所以在开发longpulling的chat之类应用非常的合适,但是其实本身也是一个高性能的http服务器,也可以作为一个WSGIServer。所以即使你的网站没有使用Tornado的框架,而是用了web.py或者是Django来开发(傻瓜万岁),这个时候Tornado依然可以用来加速你的网站。使用Tornado来代替fastCGI可以大幅提高性能,且可以承载的并发能力也有了成倍的提高(大家可以自己Profile,本文只介绍如果做)。

下面我们开始来介绍如何配置。这里我们假设你的一个用Django写的网站在一台Linux的服务器上快乐地着(ubuntu or CentOS,没试过在其他发行版折腾过,windows?你在说笑吧),随着网站越来越红火,你越发感觉服务器不堪重负。这个时候Tornado出现了,他可以让你再苟延残喘好几个月,节约一大把的银子去把妹………….回到正题。根据官网的推荐部署方式,我们还是采用Nginx通过upstream来反向代理到N个Tornado的服务器实例上的部署方式。so

Setp1:安装supervisord

由于Tornado并没有自身提供Daemon的能力,所以我们需要用一个服务管理工具来管理Tornado的进程,supervisord是用Python实现的一款非常实用的进程管理工具。可以很方便的管理N过进程,且支持进程分组。Supervisord可以通过sudo easy_install supervisor安装,当然也可以通过Supervisord官网下载后setup.py install安装。

Step2: 给Django的站点增加一个Tornado的服务器文件(比如serv.py)

创建一个文件Serv.py在Django站点的根目录,内容如下:

__author__ = ‘alexander’
import os
import sysfrom tornado.options import options, define, parse_command_line
import django.core.handlers.wsgi
import tornado.httpserver
import tornado.ioloop
import tornado.web
import tornado.wsgi

_HERE = os.path.dirname(os.path.abspath(__file__))
sys.path.append(_HERE)
sys.path.append(os.path.join(_HERE, ‘..’))
sys.path.append(os.path.join(_HERE, ‘../contrib’))
os.environ[‘DJANGO_SETTINGS_MODULE’] = “settings”

def main(port):
wsgi_app = tornado.wsgi.WSGIContainer(
django.core.handlers.wsgi.WSGIHandler())
tornado_app = tornado.web.Application(
[(‘.*’, tornado.web.FallbackHandler, dict(fallback=wsgi_app)),
])
server = tornado.httpserver.HTTPServer(tornado_app)
server.listen(port)
tornado.ioloop.IOLoop.instance().start()

if __name__ == ‘__main__’:
main(int(sys.argv[1]))

 

我这里通过第一个参数来指定Tornado服务监听的端口。这样比较灵活,这点我们在后面的步骤会用到。这个时候我们可以通过

python Serv.py 8000

这个命令来启动服务器

Step3: 配置Supervisord

第一步安装的Supervisord还没有配置,所以我们需要先创建一个配置文件的样板。在root权限下执行

echo_supervisord_conf > /etc/supervisord.conf

这个时候在/etc/创建了配置文件,用vim打开这个文件,在配置文件的屁股后面加上以下这一段

[program:web]
command=python /var/www/site/Serv.py 80%(process_num)02d
process_name=%(program_name)s_%(process_num)02d
umask=022
startsecs=0
stopwaitsecs=0
redirect_stderr=true
stdout_logfile=/tmp/codoon.log
numprocs=4
numprocs_start=1

 

这个配置会启动4个Tornado的服务进程分别监听 8001,8002,8003,8004 这四个端口

command这一行是要执行的命令,这里是用 python /var/www/site/Serv.py 端口号来启动Tornado的服务进程 80%(process_num)02d 的用途是通过进程编号来生成端口号。下面的process_name这个参数也会用到。这里要指定的文件名就是上一步我们创建那个Serv.py文件

process_name是进程的名字,由于这里要启动4个进程,所以要用process_num来区分

umask是程序执行的权限参数

startsecs这个参数是程序启动的等待时间

stopwaitsecs这个参数是程序停止的等待时间

redirect_stderr这个参数将错误流重定向到std的流输出,这样可以省去一个日志文件的配置,当然也可以不用这个参数分开配置日志文件

stdout_logfile 这个参数是STD流输出日志文件的路径,Tornado会输出所有的请求和错误信息,通过这个可以统一做日志处理,分隔什么的,在程序里就只需要print到std流就行了。

numprocs 这个参数指定了进程的数量,这里是4,表明要启动4个Tornado进程

numprocs_start 这个参数指定了进程号的起始编号,这里是1,这样前面的command和process_name里的%(process_num)02d部分就会在执行的时候被替换为01~05的字符串

配置修改完成后:wq保存退出,执行:

supervisorctl reload

重新加载配置后,这些进程就启动起来了

Step4:修改配置Nginx

首先找到在vhost目录里你的站点配置文件,打开后,在头上增加upstream的内容

upstream frontends {

server 127.0.0.1:8001;

server 127.0.0.1:8002;

server 127.0.0.1:8003;

server 127.0.0.1:8004;

}

然后在Server配置节里找到

location / { 这个配置节

以前是用的FastCGI,所以里面的配置可能是这样子的

# host and port to fastcgi server
#fastcgi_pass 127.0.0.1:8081;
#fastcgi_param PATH_INFO $fastcgi_script_name;
#fastcgi_param REQUEST_METHOD $request_method;
#fastcgi_param QUERY_STRING $query_string;
#fastcgi_param CONTENT_TYPE $content_type;
#fastcgi_param CONTENT_LENGTH $content_length;
#fastcgi_pass_header Authorization;
#fastcgi_param REMOTE_ADDR $remote_addr;
#fastcgi_param SERVER_PROTOCOL $server_protocol;
#fastcgi_param SERVER_PORT $server_port;
#fastcgi_param SERVER_NAME $server_name;
#fastcgi_intercept_errors off;

把这些统统删掉,变成了这样

location / {

}

在{}中加入upstream的配置,变成如下样子
location / {
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_pass http://frontends;
proxy_next_upstream error;

}

保存配置文件后执行  让nginx重启的指令 nginx -s reload(注意 nginx文件在不同发行版中位置有差别)

然后你就能够通过域名看到你的网站了,试试是不是快多了

注意:生产系统下开启多少个Tornado进程比较好呢,这个见仁见智了,据我压力测试的结果看来,用CPU核数*2的数量最好,再多 就浪费了没有提升(为什么乘2?因为有种CPU上的技术叫超线程)。我的VPS上用的4个进程。如果是8核IntelCPU要挖尽CPU潜能的话需要开16个进程

那么现在很流行用一些高性能的nonblock的app server来host Django的应用,这些Server可以看做是一个单进程单线程的程序,然后用nginx在前端反向代理并且负载均衡到N多个后端工作进城来充分利用多CPU的性能,当然这部分的配置工作在上回已经说得很清楚了。但是对于Django来说有一个问题。因为Django的数据库连接是在查询的时候实时创建的,用完就会关掉,这样就会频繁的开闭连接。但是对于Tornado这种Server来说这种方式是低效的。这种Server最高效的工作模式是每个进程开启一个连接,并长期保持不关闭。本文的目的就是尝试使Django改变一贯的作风,采用这种高效的工作模式。本文基于Django1.3的版本,如果是低版本可以稍加更改一样可以使用。

Django的数据库可以通过配置使用专门定制的Backend,我们就从这里入手。

首先我们看看Django自带的Backend是如何实现的。在Django官网上可以看到自带MySql的Package结构,可以点击 此处 前往瞻仰。

通观源码我们可以发现,Django基本上是封装了MySQLdb的Connection和Cursor这两个对象。而且重头实现整个Backend既不实际而且也不能从根本上解决问题。所以我们可以换一个思路。所有的数据库操作都是从获取Connection对象开始的,而获取Connection对象只有一个入口,就是MySQLdb.connect这个函数。所以我们只需要包装MySQLdb这个模块,用我们自己的connect方法替代原本的,这样就从根源上解决了问题。我们在包装器内部维护MySQLdb的Connection对象,使其保持长连接,每次connect被调用的时候判断一下,如果连接存在就返回现有连接,不就完美了吗?所以我们可以分分钟写下第一个解决方案:

proxies = {}

class _DbWrapper():
def __init__(self,module):
self.connection=None #这个就是维护的长连接对象
self.db=module           #这个是被包装的原生MySQLdb的module

def __getattr__(self, key):
return getattr(self.db, key)   #代理所有不关心的函数

def connect(self,*argv,**kwargv):
“”“
替换原有的connection对象
”“”
if not self.connection:
self.connection=self.db.connect(*argv,**kwargv)
return _ConnectionWrapper(self.connection)

def manage(module,keepalive=7*3600):
“”“
返回代替原生MySQLdb模块的对象
”“”
try:
return proxies[module]
except KeyError:
return proxies.setdefault(module,_DbWrapper(module))

把上面代码存到一个叫pool.py的文件里。然后把Django源码里的db/backend/mysql这个package拷贝出来,单独存到我们project目录里一个mysql_pool的目录里。然后修改其中的base.py,在顶上import的部分,找到 import MySQLdb as Database 这句,用下面代码替换之

try:
import MySQLdb as Database
Database = pool.manage(Database)
except ImportError, e:
from django.core.exceptions import ImproperlyConfigured
raise ImproperlyConfigured(“Error loading MySQLdb module: %s” % e)

这样我们就用自己的模块替换了MySQLdb的,当要connect的时候判断到有连接的时候就不重新创建连接了。

把站点跑起来看,结果如何?刷新几次后报错了。Why?看看日志可以看到如下的错误:

Traceback (most recent call last):
File “/home/www/.virtualenvs/django13/lib/python2.7/site-packages/gevent/wsgi.py”, line 114, in handle
result = self.server.application(env, self.start_response)
File “/home/www/.virtualenvs/django13/lib/python2.7/site-packages/django/core/handlers/wsgi.py”, line 275, in __call__
signals.request_finished.send(sender=self.__class__)
File “/home/www/.virtualenvs/django13/lib/python2.7/site-packages/django/dispatch/dispatcher.py”, line 172, in send
response = receiver(signal=self, sender=sender, **named)
File “/home/www/.virtualenvs/django13/lib/python2.7/site-packages/django/db/__init__.py”, line 85, in close_connection
conn.close()
File “/home/www/.virtualenvs/django13/lib/python2.7/site-packages/django/db/backends/__init__.py”, line 244, in close
self.connection.close()

看来我们光是包装了MySQLdb本身还不行,在connect后Django获取了Connection的对象,之后就能为所欲为,他用完后很自觉的关掉了,因为他直觉的以为每次connect都拿到了新的Connection对象。所以我们必须把Connection对象也包装了了。所以升级后的解决方案代码如下:

proxies = {}

class _ConnectionWrapper(object):
“””
用来包装Connection的类
“””
def __init__(self,conn):
self.conn=conn

def close(self):
“””
屏蔽掉关闭连接的行为
“””
pass

def __getattr__(self,key):
“””
把其他属性都原封不动的代理出去
“””
return getattr(self.conn, key)

class _DbWrapper():
“””
代理MySQLdb模块的对象
“””
def __init__(self,module):
self.connection=None  #HOLD住的长连接
self.db=module            #原始的MySQLdb模块

def __getattr__(self, key):
“””
代理除connect外的所有属性
“””
return getattr(self.db, key)

def connect(self,*argv,**kwargv):
if not self.connection:
self.connection=self.db.connect(*argv,**kwargv)
return _ConnectionWrapper(self.connection)

def manage(module):
try:
return proxies[module]
except KeyError:
return proxies.setdefault(module,_DbWrapper(module))

我们增加了一个_ConnectionWrapper类来代理Connection对象,然后屏蔽掉close函数。把站点跑起来后发现不会出现之前的问题了,跑起来也顺畅不少。但是过了几个小时后问题又来了。因为MySQLdb的Connection有个很蛋痛的问题,就是连接闲置8小时后会自己断掉。不过要解决这个问题很简单,我们发现连接如果闲置了快8小时就close掉重新建立一个连接不就行了么?所以最后解决方案的代码如下:

import time

proxies = {}

class _ConnectionWrapper(object):
def __init__(self,conn):
self.conn=conn

def close(self):
pass

def __getattr__(self,key):
return getattr(self.conn, key)

class _DbWrapper():
def __init__(self,module,max_idle):
self.connection=None
self.db=module
self.max_idle=max_idle
self.connected=0

def __getattr__(self, key):
return getattr(self.db, key)

def connect(self,*argv,**kwargv):
if not self.connection ortime.time()-self.connected>=self.max_idle:
try:
if self.connection:
self.connection.close()
except:
pass
self.connection=self.db.connect(*argv,**kwargv)
self.connected=time.time()
return _ConnectionWrapper(self.connection)

def manage(module,keepalive=7*3600):
try:
return proxies[module]
except KeyError:
return proxies.setdefault(module,_DbWrapper(module,keepalive))

就此问题解决,世界终于清净了

发表评论

电子邮件地址不会被公开。 必填项已用*标注