原文：http://www.cnblogs.com/Alexander-Lee/archive/2011/11/12/django_long_connection.html
书接上回
上回我们说到：《在生产系统使用Tornado WebServer来代替FastCGI加速你的Django应用 》
那么现在很流行用一些高性能的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被调用的时候判断一下，如果连接存在就返回现有连接，不就完美了吗？所以我们可以分分钟写下第一个解决方案：