Django 源码小剖: 更高效的 URL 调度器(URL dispatcher)

效率问题

django 内部的 url 调度机制说白了就是给一张有关匹配信息的表, 这张表中有着 url -> action 的映射, 当请求到来的时候, 一个一个(遍历)去匹配. 中, 则调用 action, 产生相应数据返回; 不中, 则会产生 404 等的错误, 而 django 中有内置 404 等错误响应方法.

这种方法和 MFC 里 message map 差很少, 从项目实践(特别是配置 urls.py 文件)就能够猜到大概是这样一种工做模式.

注意上面关于 django url 调度机制的白话描述中的「一个一个」, 这里就有效率上的问题了. 假若业务逻辑不复杂, 且访问量不高, 系统是没有问题的; 但若是业务逻辑太复杂(直观的表述是 urls.py 中的匹配条目繁杂), 如此加之高访问量, 会加剧系统的负担, 试想最坏的状况是每个请求都会从头至尾匹配一次, 让人感到不爽.

一种更好的解决方法

策略仍是有的, 由于业务逻辑不会常常变动, 至少不会没几分钟就变动一次, 因此能够借助哈希表来达到快速匹配的目的. 有关哈希表能够参照以前写的一篇文章: 私房STL之hash_set和hash_map

哈希表

通常的作法举例以下:

http://example.com/aaaaa/
http://example.com/bbbbb/
http://example.com/ccccc/
http://example.com/ddddd/
http://example.com/eeeee/
abcde 表示 web 应用的功能模块.

为 aaaaa,bbbbb...都计算获得哈希值 hash(aaaaa),hash(bbbbb)...

当请求 http://example.com/aaaaa/ 到来时候, 提取 aaaaa, 计算哈希值直接在哈希表中定位匹配条目. 通常的作法是这样, 还能够顺着这样的思路继续改进. 譬如, 存在更为复杂的功能, 并且这个功能在 aaaaa 的基础上创建起来: http://example.com/aaaaa/xxxxx, 这时候, 也能够计算 hash(aaaaaxxxxx) 加入到哈希表中.

那是否是每一个请求到来启动 web 应用程序的时候都要计算 urls.py 中的条目的哈希值? 并不须要, 能够新建一个 url 服务进程, 只专门维护哈希表, 从 urls.py 中计算哈希表; 通由内存映射技术, web 应用程序能够方便读取哈希表, 而且能够重复利用.

什么提到会调用 url 对应的 action, 并返回响应数据, django 是怎么返回的. 我已经在 github 备份了 Django 源码的注释: Decode-Django, 有兴趣的童鞋 fork 吧.

捣乱 2013-9-18

http://daoluan.net