质量度量平台性能优化-1

2014年，我们独立开发了代号为AEW的质量度量平台，里面的东西还算比较丰富，包括线下Bug、线上故障的统计、分析、展示（趋势图），包括研发流程（持续集成）、测试环境的使用情况展示，包括测试环境中网络、DB、应用的状态监控和月度统计报告，还有App客户端真是用户的log分析（crash率、API调用出错、慢响应等）、Nginx服务端的HTTP状态码统计与趋势展示。

这个平台的是一个Web平台，主要使用Python开发，主要使用了Django框架，前端还有Bootstrap、Angular.js等，REST API部分使用django-rest-framework，对于一些分布式任务使用了Celery框架。服务是部署在CentOS上的，使用到了Nignx。

随着系统的推广使用，越来越多的人开始关注这个系统，加之系统自身的前端、后端设计时对性能方面都没有做太多的优化（当然在写REST API时还是注意了它的响应时间的），所以最近抽空余时间做一些性能优化吧。这个“质量度量平台性能优化”系列，可能会有几篇文章，分别涉及到：部署优化、前端优化、异步处理、REST API优化等几个方面。

本文是关于部署优化的，主要是“动静分离”。

了解到用Django的“python manage.py runserver”运行服务器时，它只是一个供开发方便使用的服务器，是一个单进程的Server。我用Firebug、Chrome的开发者工具简单看了下，我们的请求数（特别是CSS、JS）是比较多的，首页就有47个之多（其中css和js超过40个）。我想到了刚毕业不久时，在做一些性能优化项目时，大家提到的“动静分离”，将动态资源和静态资源分别部署，静态资源竟可能用CDN和用浏览器自身缓存。作为内部系统，并发量不是很大，暂时就是用Django自带的开发服务器部署的，通过Nginx直接将请求转到Django服务器上。我们都知道Nginx服务器处理静态请求是很牛的，所以，今天我只做了一个简单的事情，将css/js/imgage等静态内容（放在我们的static目录中）直接交给Nginx来处理，这样效率会高很多。（注：请求过多的问题，下次在前端优化中专门来做；后面当然还是要像Instagram那样用Gunicorn来做WSGI服务器配合Django一起使用）

在Nginx conf文件中，将/static映射到项目的static目录下；其余请求转发给django的server来处理，配置如下：

这个“动静分离”的效果如何呢？
系统首页打开浏览器中加载时间（无本地cache的情况下），优化前4.24s，优化后0.42s，效率提升达到9倍之多。（当然这是因为Django自带的开发用的server太弱了；Nginx又太强大了。）充分发挥了Nginx处理静态请求的强项。