最近在做对django性能的测试,发现LocalMiddleware.process_request占用时间较长,本机大约占用60~70毫秒。一直以为是I18n模块的问题,经详细的调试,发现主要cpu都在 request.session.get('django_language')一句被占用了。
原来是session的性能问题。
session的backend应当设为cache或cache_db。
使用cache时发现,memcached的python客户端包没有很好的选择,因为cmemcached已经不再维护了,有几个可以选择的库,django所支持的cmemcached,python-memcached都不是很好的选择。
python-libmemcached性能不错,似乎是豆瓣的成员维护的项目,但django目前不支持
[url]http://pypi.python.org/pypi/pylibmc[/url] 似乎是另一个积极维护的python memcached客户端
遗憾的是这两个目前django不支持,决定先用本地mem缓存做测试,等django集成了这些高性能bindings再说吧
[url]http://code.djangoproject.com/ticket/12427[/url]
cache key的长度对性能理论上应是有影响的,虽然目前没有做过测试。
这两天做了个小程序来做key的长度转换,将所有的key转换为长度很小的key,但目前担心key转换本占用了过多性能
原来是session的性能问题。
session的backend应当设为cache或cache_db。
使用cache时发现,memcached的python客户端包没有很好的选择,因为cmemcached已经不再维护了,有几个可以选择的库,django所支持的cmemcached,python-memcached都不是很好的选择。
python-libmemcached性能不错,似乎是豆瓣的成员维护的项目,但django目前不支持
[url]http://pypi.python.org/pypi/pylibmc[/url] 似乎是另一个积极维护的python memcached客户端
遗憾的是这两个目前django不支持,决定先用本地mem缓存做测试,等django集成了这些高性能bindings再说吧
[url]http://code.djangoproject.com/ticket/12427[/url]
cache key的长度对性能理论上应是有影响的,虽然目前没有做过测试。
这两天做了个小程序来做key的长度转换,将所有的key转换为长度很小的key,但目前担心key转换本占用了过多性能