前言虽然根据经验来看，许多简单Django应用的性能问题都来源于数据库IO（而这可以通过聚合查询等手段进行优化），但premature optimization is the root of all evil，定位性能问题的具体位置仍然是最应该先做的事。和其它相对独立的Python代码不同，Django的视图函数代码与Django框架的耦合度很高，这给对代码的性能分析带来了一些困难。但幸运的是，D

前言在前一篇文章中，我介绍了测量执行Python代码所需要的总体时间的几种方法。而在实际的性能分析场景中，目标代码的逻辑往往比较复杂，光靠总体执行耗时并不能帮助我们快速定位性能瓶颈。这个时候就需要请出Python的标准库：cProfile（官方文档）来对代码进行细致的性能分析了。和前一篇文章一样，本文所使用的测试平台为Ubuntu 18.04+Python 3.6，并使用代码文件slow_func

前言我们怎样知道执行某个Python文件、某个函数、某段代码所耗费的总体时间？这是这篇文章尝试去回答的问题。作为样例，本文使用slow_func.py来进行性能分析，内容如下： 1234567891011121314# coding:utf-8import timeimport randomdef func1(): time.sleep(1) # 等待一秒def func2(): f

前言在实际部署Python Web应用时，我们往往会采用类似Nginx->uWSGI/Gunicorn->Python的三层架构。使用Nginx而不是直接使用uWSGI来处理HTTP请求的理由主要有以下几点： Nginx更安全； 需要实现负载均衡/URL转发； Nginx处理静态文件更快，缓存头更完善。 但在某些诸如简单Web应用、外部统一网关、单机单容器、内网环境等部署