Python系列---Django框架性能优化

Django

Django是什么？

Django 是一个开放源代码的 Web 应用框架，由 Python 写成。采用了 MVT 的软件设计模式，即模型 Model，视图 View 和模板 Template。它最初是被开发来用于管理劳伦斯出版集团旗下的一些以新闻内容为主的网站的。并于 2005 年 7 月在 BSD 许可证下发布。

这套框架是以比利时的吉普赛爵士吉他手 Django Reinhardt 来命名的。

Django 的主要目标是使得开发复杂的、数据库驱动的网站变得简单。Django 注重组件的重用性和“可插拔性”，敏捷开发和 DRY 法则（Don’t Repeat Yourself）。在 Django 中 Python 被普遍使用，甚至包括配置文件和数据模型。

Django 于 2008 年 6 月 17 日正式成立基金会。

Django 框架的核心包括：一个 面向对象 的映射器，用作数据模型（以 Python 类的形式定义）和关系型数据库间的介质；一个基于正则表达式的 URL 分发器；一个视图系统，用于处理请求；以及一个模板系统。

核心框架中还包括：

• 一个轻量级的、独立的 Web 服务器，用于开发和测试。
• 一个表单序列化及验证系统，用于 HTML 表单和适于数据库存储的数据之间的转换。
• 一个缓存框架，并有几种缓存方式可供选择。
• 中间件支持，允许对请求处理的各个阶段进行干涉。
• 内置的分发系统允许应用程序中的组件采用预定义的信号进行相互间的通信。
• 一个序列化系统，能够生成或读取采用 XML 或 JSON 表示的 Django 模型实例。
• 一个用于扩展模板引擎的能力的系统。

Django 包含了很多应用在它的 contrib 包中，这些包括：

• 一个可扩展的认证系统
• 动态站点管理页面
• 一组产生 RSS 和 Atom 的工具
• 一个灵活的评论系统
• 产生 Google 站点地图（Google Sitemaps）的工具
• 防止跨站请求伪造（cross-site request forgery）的工具
• 一套支持轻量级标记语言（Textile 和 Markdown）的模板库
• 一套协助创建地理信息系统（GIS）的基础框架

Django 可以运行在启用了 mod_python 的 Apache 2 上，或是任何 WSGI 兼容的 Web 服务器。Django 也有启动 FastCGI 服务的能力，因此能够应用于任何支持 FastCGI 的机器上。

下列数据库引擎被 Django 官方支持：PostgreSQL、MySQL、SQLite、Oracle

Microsoft SQL Server 的适配器正在开发中，处于试验阶段。（注：SQL Server 的支持在 1.0 版本中已经被完全去除）

自 Django 1.0 起，已经可以利用 Jython 运行在任何 J2EE 服务器。除 CPython 外，Django 当前官方支持使用 Jython 2.7b2 运行，但不保证与 CPython 上的行为完全兼容，并应预期一些功能（如使用 Pillow 的部分）无法使用。

Django做什么？

Django 是一个开放源代码的高级 PYTHON WEB 开发框架，非常出色，使用 Django 的能力可能是学习 Python 的最大优势之一。利用 Django 的模型 Model，视图 View 和模板 Template，可以轻松构建可供部署的应用程序。

Python 下有许多款不同的 Web 框架。Django 是重量级选手中最有代表性的一位。许多成功的网站和 APP 都基于 Django。

Django 的主要目标是使得开发复杂的、数据库驱动的网站变得简单。Django 注重组件的重用性和“可插拔性”，敏捷开发和 DRY 法则（Don’t Repeat Yourself）。在 Django 中 Python 被普遍使用，甚至包括配置文件和数据模型。

Django 框架的核心包括：一个 面向对象 的映射器，用作数据模型（以 Python 类的形式定义）和关系型数据库间的介质；一个基于正则表达式的 URL 分发器；一个视图系统，用于处理请求；以及一个模板系统。

Python中的GIL

在Python中GIL是Global Interpreter Lock，即全局解释锁的缩写，保证了同一时刻只有一个线程在一个CPU上执行字节码，无法将多个线程映射到多个CPU上。这是CPython解释器的缺陷，由于CPython是大部分环境下默认的Python执行环境，而很多库都是基于CPython编写的，因此很多人将GIL归结为Python的问题。

这也是使得标准版本的Python并不能实现真正的多线程并发的直接原因。简单来说就是，一个Python进程永远不能在同一时刻使用多个CPU核心。GIL被设计来保护线程安全，由于多线程共享变量，如果不能很好的进行线程同步，多线程非常容易将线程改乱。

官方解释：在cpython中，全局解释器锁(gil)是一个互斥体，它阻止多个本机线程同时执行python字节码。这个锁是必要的，主要是因为cpython的内存管理不是线程安全的。(然而，由于gil的存在，其他特性已经依赖于它所执行的保证。)

CGI

什么是CGI

CGI全称是“公共网关接口”(Common Gateway Interface)，HTTP服务器与你的或其它机器上的程序进行“交谈”的一种工具，其程序须运行在网络服务器上。
CGI可以用任何一种语言编写，只要这种语言具有标准输入、输出和环境变量。如php,perl,tcl等。

什么是FastCGI

FastCGI像是一个常驻(long-live)型的CGI，它可以一直执行着，只要激活后，不会每次都要花费时间去fork一次(这是CGI最为人诟病的fork-and-execute 模式)。它还支持分布式的运算, 即 FastCGI 程序可以在网站服务器以外的主机上执行并且接受来自其它网站服务器来的请求。
FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。众所周知，CGI解释器的反复加载是CGI性能低下的主要原因，如果CGI解释器保持在内存中并接受FastCGI进程管理器调度，则可以提供良好的性能、伸缩性、Fail- Over特性等等。

FastCGI与CGI特点

1、如CGI，FastCGI也具有语言无关性.
2、如CGI, FastCGI在进程中的应用程序，独立于核心web服务器运行,提供了一个比API更安全的环境。(APIs把应用程序的代码与核心的web服务器链接在一起，这意味着在一个错误的API的应用程序可能会损坏其他应用程序或核心服务器; 恶意的API的应用程序代码甚至可以窃取另一个应用程序或核心服务器的密钥。)
3、FastCGI技术目前支持语言有：C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby等。相关模块在Apache, ISS, Lighttpd等流行的服务器上也是可用的。
4、如CGI，FastCGI的不依赖于任何Web服务器的内部架构，因此即使服务器技术的变化, FastCGI依然稳定不变。

FastCGI的工作原理

1、Web Server启动时载入FastCGI进程管理器（IIS ISAPI或Apache Module)
2、FastCGI进程管理器自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web Server的连接。
3、当客户端请求到达Web Server时，FastCGI进程管理器选择并连接到一个CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi。
4、FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接时，请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个连接。 在CGI模式中，php-cgi在此便退出了。
在上述情况中，你可以想象CGI通常有多慢。每一个Web请求PHP都必须重新解析php.ini、重新载入全部扩展并重初始化全部数据结构。使用FastCGI，所有这些都只在进程启动时发生一次。一个额外的好处是，持续数据库连接(Persistent database connection)可以工作。

FastCGI的不足

因为是多进程，所以比CGI多线程消耗更多的服务器内存，PHP-CGI解释器每进程消耗7至25兆内存，将这个数字乘以50或100就是很大的内存数。
Nginx 0.8.46+PHP 5.2.14(FastCGI)服务器在3万并发连接下，开启的10个Nginx进程消耗150M内存（15M10=150M），开启的64个php-cgi进程消耗1280M内存（20M64=1280M），加上系统自身消耗的内存，总共消耗不到2GB内存。如果服务器内存较小，完全可以只开启25个php-cgi进程，这样php-cgi消耗的总内存数才500M。
上面的数据摘自Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建胜过Apache十倍的Web服务器(第6版)

什么是PHP-CGI

PHP-CGI是PHP自带的FastCGI管理器
PHP-CGI的不足
1、php-cgi变更php.ini配置后需重启php-cgi才能让新的php-ini生效，不可以平滑重启
2、直接杀死php-cgi进程,php就不能运行了。(PHP-FPM和Spawn-FCGI就没有这个问题,守护进程会平滑从新生成新的子进程。）

什么是PHP-FPM

PHP-FPM是一个PHP FastCGI管理器，是只用于PHP的,可以在 http://php-fpm.org/download 下载得到.
PHP-FPM其实是PHP源代码的一个补丁，旨在将FastCGI进程管理整合进PHP包中。必须将它patch到你的PHP源代码中，在编译安装PHP后才可以使用。
相对Spawn-FCGI，PHP-FPM在CPU和内存方面的控制都更胜一筹，而且前者很容易崩溃，必须用crontab进行监控，而PHP-FPM则没有这种烦恼。
PHP5.3.3已经集成php-fpm了，不再是第三方的包了。PHP-FPM提供了更好的PHP进程管理方式，可以有效控制内存和进程、可以平滑重载PHP配置，比spawn-fcgi具有更多有点，所以被PHP官方收录了。在./configure的时候带 –enable-fpm参数即可开启PHP-FPM。

什么是Spawn-FCGI

Spawn-FCGI是一个通用的FastCGI管理服务器，它是lighttpd中的一部份，很多人都用Lighttpd的Spawn-FCGI进行FastCGI模式下的管理工作，不过有不少缺点。而PHP-FPM的出现多少缓解了一些问题，但PHP-FPM有个缺点就是要重新编译，这对于一些已经运行的环境可能有不小的风险(refer)，在php 5.3.3中可以直接使用PHP-FPM了。
Spawn-FCGI目前已经独成为一个项目，更加稳定一些，也给很多Web 站点的配置带来便利。已经有不少站点将它与nginx搭配来解决动态网页。
最新的lighttpd也没有包含这一块了(http://www.lighttpd.net/search?q=Spawn-FCGI )，但可以在以前版本中找到它。在lighttpd-1.4.15版本中就包含了(http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz)
目前Spawn-FCGI的下载地址是http://redmine.lighttpd.net/projects/spawn-fcgi ，最新版本是http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz
注：最新的Spawn-FCGI可以到lighttpd.net网站搜索“Spawn-FCGI”找到它的最新版本发布地址

PHP-FPM与spawn-CGI对比测试

PHP-FPM的使用非常方便,配置都是在PHP-FPM.ini的文件内，而启动、重启都可以从php/sbin/PHP-FPM中进行。更方便的是修改php.ini后可以直接使用PHP-FPM reload进行加载，无需杀掉进程就可以完成php.ini的修改加载
结果显示使用PHP-FPM可以使php有不小的性能提升。PHP-FPM控制的进程cpu回收的速度比较慢,内存分配的很均匀。
Spawn-FCGI控制的进程CPU下降的很快,而内存分配的比较不均匀。有很多进程似乎未分配到,而另外一些却占用很高。可能是由于进程任务分配的不均匀导致的.而这也导致了总体响应速度的下降。而PHP-FPM合理的分配，导致总体响应的提到以及任务的平均。

uwsgi

基于Python的Web项目部署起来真是头痛，常见的部署方法有：

◆fcgi：用spawn-fcgi或者框架自带的工具对各个project分别生成监听进程，然后和http服务互动。

◆wsgi：利用http服务的mod_wsgi模块来跑各个project。

无论哪种都很麻烦，apache的mod_wsgi配置起来麻烦，内存占用还大，如果要加上nginx作为静态页面的服务器那就更麻烦了；

如果Python中能有个什么东西像php-cgi一样监听同一端口，进行统一管理和负载平衡，那真是能省下大量的部署功夫。这就是uwsgi为什么会诞生!

uWSGI 是一个“旨在开发用于构建托管服务的完整堆栈”的软件应用程序。它以 Web 服务器网关接口命名，这是该项目支持的第一个插件。 uWSGI 通常用于与 Web 服务器（如 Cherokee 和 Nginx）一起提供 Python Web 应用程序，后者为 uWSGI 的本机 uwsgi 协议提供直接支持。

uWSGI 是一个 Web 服务器，它实现了 WSGI 协议、uwsgi、http 等协议。Nginx 中 HttpUwsgiModule 的作用是与 uWSGI 服务器进行交换。

要注意 WSGI / uwsgi / uWSGI 这三个概念的区分。

• WSGI 是一种通信协议。
• uwsgi 是一种线路协议而不是通信协议，在此常用于在 uWSGI 服务器与其他网络服务器的数据通信。
• 而 uWSGI 是实现了 uwsgi 和 WSGI 两种协议的 Web 服务器。

uwsgi 协议是一个 uWSGI 服务器自有的协议，它用于定义传输信息的类型（type of information），每一个 uwsgi packet 前 4byte 为传输信息类型描述，它与 WSGI 相比是两样东西。

uWSGI，既不用wsgi协议也不用fcgi协议，而是自创了一个uwsgi的协议，据说该协议大约是fcgi协议的10倍那么快。

uWSGI的主要特点如下：

◆超快的性能。

◆低内存占用（实测为apache2的mod_wsgi的一半左右）。

◆多app管理。

◆详尽的日志功能（可以用来分析app性能和瓶颈）。

◆高度可定制（内存大小限制，服务一定次数后重启等）。

django 项目中uwsgi的process参数设置

由于Python中GIL的存在，所以为了提高并发通常使用多进程运行web程序，那么在uwsgi中该将process设置成多少呢，查阅网上，一般都是设置4个进程2个线程，还有的建议将进程数设置为CPU核心数的两倍。我们分析一下：假设一次http请求响应时间是50ms，那么在单个进程的情况下，一秒最多处理20个请求，如果有n个进程同时处理，那就是1秒内能20*n个请求。但是要注意，进程数可不是随意设置的，当你的电脑有4个核心时，你开4个进程，可以将CPU全部利用上，开的再多，由于没有更多的核心去运行进程，所以这些进程并不能同时运行，只能每个执行一段时间后，让其他进程运行，这样也就增加了单个请求的响应时间，比如设置成将uwsgi设置为8进程，这时平均响应时间大约在100ms。所以，在处理并发的时候，要考虑响应时间。在响应时间一定的情况下，单个http请求的响应时间越小，能够处理的并发越大。
下面做测试验证一下
测试机器：i5-3210(双核四线程) 内存（6G）单次http请求响应时间大约16ms （该接口基本不涉及磁盘IO，所以uwsgi没有使用多线程）
这里需要注意：上面的CPU可以理解成是四核心，但是性能会比真正的四核有损失，大约30%，具体百度。
设置uwsgi进程数为4,用ab测试，在2个、4个、8个并发的情况下的响应时间和QPS，理论上响应时间大约为
16 、 23 、45 。我们看一下实际情况：
这是并发为2的情况：

Concurrency Level:      2
Time taken for tests:   0.896 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1157000 bytes
HTML transferred:       1119100 bytes
Requests per second:    111.55 [#/sec] (mean)
Time per request:       17.929 [ms] (mean)
Time per request:       8.964 [ms] (mean, across all concurrent requests)
Transfer rate:          1260.40 [Kbytes/sec] received

这是并发为4的情况：

Concurrency Level:      4
Time taken for tests:   0.638 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1157000 bytes
HTML transferred:       1119100 bytes
Requests per second:    156.84 [#/sec] (mean)
Time per request:       25.504 [ms] (mean)
Time per request:       6.376 [ms] (mean, across all concurrent requests)
Transfer rate:          1772.09 [Kbytes/sec] received

这是并发为8的情况：

Concurrency Level:      8
Time taken for tests:   0.636 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1157000 bytes
HTML transferred:       1119100 bytes
Requests per second:    157.19 [#/sec] (mean)
Time per request:       50.894 [ms] (mean)
Time per request:       6.362 [ms] (mean, across all concurrent requests)
Transfer rate:          1776.05 [Kbytes/sec] received

可以看到上图基本验证了我的猜测。并且在并发为4的时候就达到了QPS的最高值，此时再继续增大并发，只会增加单个http请求的响应时间。我们在保证响应时间在200ms的情况，通过上面的数据，估计最高并发大约为30 ，接着去验证一下：

Concurrency Level:      30
Time taken for tests:   0.649 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1157000 bytes
HTML transferred:       1119100 bytes
Requests per second:    154.10 [#/sec] (mean)
Time per request:       194.679 [ms] (mean)
Time per request:       6.489 [ms] (mean, across all concurrent requests)
Transfer rate:          1741.15 [Kbytes/sec] received

因为，以后在设置uwsgi参数时，将process设置为CPU的核心数就可以了，如果涉及到从磁盘读取数据的情况，可以考虑加上线程。如果想增大并发能力就要办法降低单个http请求的响应时间。

绑定物理核

另一个提高性能的方法那就是绑定物理核心