质量度量平台性能优化-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处理静态请求的强项。

master

Stay hungry, stay foolish.

发表评论

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