django sweetpie 性能调优答案

【问题标题】：django tastypie performance tuningdjango sweetpie 性能调优
【发布时间】：2013-11-11 14:51:41
【问题描述】：

我有一个网站使用 django-tastypie 通过 API 向移动应用程序提供数据。在对我们的 API 进行第一次 apache-benchmark 测试时，我注意到性能不如我预期的那么好（不得不承认我没有坚实的基础来支持我的期望）。我的服务器设置如下：2.4GHZ 2核CPU，2560M内存，ubuntu12.04。我将 nginx 与 uwsgi 一起使用，将 uwsgi 设置为使用 4 个 worker，并将 nginx 与 4 个 worker_processes 一起使用。

这是我来自 API 端点的 ab 结果。该查询跨越 7 个表，有 30 多个查询，以及一堆嵌套资源。当我分析 SQL 查询时，其中只有 3 个花费超过 1 毫秒（分别为 1 毫秒、1 毫秒和 2 毫秒）。

ab -n 100 -c 8  -H 'Accept-Encoding: gzip'  "http://mysite"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking lvxingjia.cc (be patient).....done


Server Software:        nginx/1.4.1
Server Hostname:        mysite
Server Port:            80

Document Path:          mysite
Document Length:        10807 bytes

Concurrency Level:      8
Time taken for tests:   19.146 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1117500 bytes
HTML transferred:       1080700 bytes
Requests per second:    5.22 [#/sec] (mean)
Time per request:       1531.720 [ms] (mean)
Time per request:       191.465 [ms] (mean, across all concurrent requests)
Transfer rate:          57.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       16   37  56.5     23     485
Processing:   775 1455 238.1   1502    1901
Waiting:      765 1443 237.8   1488    1889
Total:        794 1492 235.7   1555    1920

Percentage of the requests served within a certain time (ms)
  50%   1555
  66%   1626
  75%   1653
  80%   1694
  90%   1758
  95%   1783
  98%   1903
  99%   1920
 100%   1920 (longest request)

我对性能调优还很陌生，如果这不是什么可怕的事情，我什至不想费心去做，因为我们现在没有太多的流量。

所以我的第一个问题是：考虑到我的服务器资源和请求的复杂性，这个数字是否合理？

我的第二个问题是，如果这个数字不可接受，我应该从哪个方面进行改进？ DB查询，行分析django？我得到了 line-profiling 结果，实际上看到 deepcopy 的一个 sweetpie 问题，其他用户也报告了这个问题，monky-patch 确实将我的性能提高了大约 30%。

我还在这里看到了一篇很棒的帖子：Bad Django / uwsgi performance，但鉴于我的服务器/请求场景，我希望对我的情况有一些看法。

谢谢！

【问题讨论】：

gzip压缩在哪里完成？在 nginx 或 django 中？什么是 gzip 压缩设置？
gzip 在 nginx 中完成。我将 gzip_http_version 设置为 1.0 以便 ab 请求可以获取 gzip 压缩的 json 数据。我可以通过 document_length 验证 gzip 是否正常工作。但实际上它并没有太大改变性能，因为我认为瓶颈不在于带宽。
实际上我问是因为当有人将gzip_comp_level 设置为大于 1 并因此性能受到影响时，这是很常见的。
如果您正在访问返回元素列表的端点，请考虑缓存响应，或者以其他方式加速序列化，因为 sweetpie 可能会在长数据序列化列表上打嗝（即使 db 查询速度非常快）。
@kroolik：缓存不是为了负载测试吗？您是否有任何关于加快序列化速度的示例或什么情况可能导致速度缓慢的示例？

标签： python django performance nginx tastypie

【解决方案1】：

您是否访问了 100 次完全相同的查询网址？如果是这样，缓存会创造奇迹。

您看到性能很差，因为所有请求都排队并按顺序处理。能够同时处理您的请求会有所帮助。您需要更多 CPU 内核来处理您的网络请求。

将您的 SQL 服务器移动到另一台机器上也可能会有所帮助。

【讨论】：

缓存是计算性能的固有部分，从您的 L1 CPU 缓存到 memcache/redis/varnish 等。通过缓存，我并不一定意味着您的 API 可能是最终的 HTML/json交付。缓存中间数据库请求也会提高性能。
就大体方向而言，tastepie 经常对嵌套资源进行查询，因为它们会通过嵌套并提取各种东西。您可以将此最小化，或最大化缓存以提高性能。这将是我开始挖掘的第一个地方。