引言
最近有个同事反映某个老旧项目总是有请求失败的情况，早期项目为了快速上线完成任务，很多代码基本是怎么方便怎么写，这样就留下了很多隐患，于是找到服务器查看日志果然发现了大量的502、499错误，然后又跟那个同事大致了解了下情况，原来是客户端最近增加了不少，并且有集中访问的情况，根据情况自己写了个测试脚本模拟真实请求开始测试，发现只要到大概200的并发，就会出现上述的错误（好吧，确实有点弱╮(╯╰)╭）
目标
以目前的访问量在不更换框架的情况下尽量把并发提高到1000以上
不影响现在的业务
服务器配置
硬件：16核CPU+32G内存
软件：gunicorn+django+postgresql
其他：gunicorn开了50个work
优化流程
先从软件配置开始查找问题，发现gunicorn没用gevent，于是增加配置如下：
#gun.conf
worker_class = "gevent"
worker_connections = 2048
workers = 33 #官方建议(2 x $num_cores) + 1
backlog = 4096
#wsgi.py(别忘了打monkey patch)
import gevent.monkey
gevent.monkey.patch_all()
测试并发达到了300，并且没有错误，这个量还远远不够，继续查找问题，发现每次测试的时候，数据库服务器负载非常之高，cpu使用率非常大，查下当前慢查询
select * from pg_stat_activity where state<>'idle' and now()-query_start > interval '1 s' order by query_start ;
果然有条很简单的查询很耗时，居然可以用12s，这能忍么，原因有张百万数据的表居然在查询条件那没建索引ㄟ( ▔, ▔ )ㄏ，建了索引之后，发现果然快了好多，至少大于1s的查询没有了，感觉正个数据库都轻松了好多，又继续300个并发走起，果然负载下来了很多，是以前的1/10，继续加大并发测试，发现大概到600的时候就开始出现错误了，同时数据库的压力也上来了，索性加个慢查询日志吧，继续看看：
log_min_duration_statement = 100ms
log_destination = 'csvlog'
发现了大量的耗时的sql类似这种：
select * from tablename where upper(columnname) = upper(aaa);
之后去代码里看了下，有几条django orm 语句类似这样的，忽略大小写：
XXX.objects.filter(xxx__iexact='aaa',xxx__iexact='bbb'）
用了这个__iexact之后，数据库就会进行upper操作,django源码里的一段代码：
operators = {
'exact': '= %s',
'iexact': '= UPPER(%s)',
'contains': 'LIKE %s',
'icontains': 'LIKE UPPER(%s)',
'regex': '~ %s',
'iregex': '~* %s',
'gt': '> %s',
'gte': '>= %s',
'lt': '< %s',
'lte': '<= %s',
'startswith': 'LIKE %s',
'endswith': 'LIKE %s',
'istartswith': 'LIKE UPPER(%s)',
'iendswith': 'LIKE UPPER(%s)',
}
在stackoverflow上查到的一条建议：
I'd say your best bet is to simply create an index with upper(column) as well or instead of, and go have a drink
跟业务那边沟通了下，数据都是非常标准的不会出现大小写的问题，所以改用exact，再次测试600并发，果然负载小了很多，直到并发达到1000开始出错，也算有点进步了~
进一步优化，由于这个服务每次请求都会往数据库写一条数据，想了下能不能改成异步的，查找官网资料，直到如下配置：
#postgresql.conf
synchronous_commit = off
这个配置安全性还是很高的，几乎不会造成数据丢失参考链接
到目前为止并发已经达到1000没有报任何错误了，因为这是线上实时跑的业务，还没想到更换框架
网友评论