nginx中map模块的使用及性能测试
最近我操刀了leetcode的论坛迁移，整个过程持续了几周的时间，总算暂时告了一个段落。常使用leetcode论坛的用户应该已经发现论坛已经大变样了吧~
期间遇到了不少坑坑洼洼，将来也还会有好多问题等待去一一解决。关于这个迁移过程中的收货，这篇文章中就不细说了，有时间再另开一篇博文。这篇文章主要关注在url-mapping以及它的性能问题。
问：url-mapping的问题从何而来呢？
旧的论坛和新的论坛是两个不同的discuss框架。前者是 phpbb ，现在是 nodebb 。两者的 url routing 完全不一样，比如说同一个topic，
在原来的url是:
http://hostname/discuss/<topic_id>/<topic_name> 在新的论坛中是:
http://hostname/topic/<topic_id>/<topic_slug> (这里就不讨论两者甚至连 topic_id 都不一样的问题了)。
而在广袤的互联网海洋中，旧论坛的url可能到处都存在。我们不希望在论坛迁移后，用户点那些链接就失效了。我们希望的是用户访问旧的url可以被重定向到新论坛的某个地址。所以就产生了url-mapping的问题。
方法
生成url-mapping
感谢 nodebb-plugin-import 提供了数据迁移以后自动生成url-mapping的方式，省了我自己写脚本生成这些mapping的时间。每一条mapping大致是这样的:
~^/discuss/questions/oj/add-two-numbers/b(/?[^/]*)*/?$ /category/10/add-two-numbers;
其中的 slug 和 id 的mapping是由插件生成的。 regular expression 是为了匹配url中如果有param添加的。
Nginx Map
官方文档 的demo可能对于刚想上手的同学来说不是那么友好，还是直接看现成的配置学得快:
http { ... map_hash_max_size 204800; map_hash_bucket_size 204800; map $request_uri $new { include /path/of/your/map/file; } include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; ... } server { ... if ($new) { rewrite ^ https://discuss.leetcode.com$new redirect; } location / { ... } ... } 在server规则匹配中，$new值不为空，说明当前要访问的url已经在http模块的mapping文件中匹配到了，这个时候就不走各种 location 模块了，直接rewrite成新的地址。 注 :这里要是做成proxy_pass也行，后面的测试中就采用了proxy_pass。但线上的环境，担心nginx的压力太大了，就采用了rewrite方式给它减减压。
测试
考虑到mapping的条目有点多，几万量级，又都是正则匹配。每个请求来的时候都会先去看看mapping中有没有，即使mapping使用的是hash的方式也不免会让我对它的性能产生一些担忧，所以性能测试就必须要来一发了。
测试方案:
- 在新机器上跑helloworld
- 自动生成随机100个url-mapping，都重定向到helloworld
- 使用abtest分别对helloworld和随机url作压测
- 增大url-mapping的条目，重复1,2
压测机器
临时租了两台阿里云服务器(因为是临时的，所以我也就不在意在后文暴露ip了)。
配置都是：1核，2048M内存，40G硬盘。
一台用作nginx和helloworld程序，一台专门做abtest。
注：abtest也在阿里云执行只要是为了在一个数据中心降低网络延迟。最后发现效果真不错，rps从100多直接飙升到2700多。
helloworld
采用了nodejs的helloworld:
varhttp =require('http'); vari =0; http.createServer(function(req, res){ console.log(i++); res.writeHead(200, {'Content-Type':'text/plain'}); res.end('Hello World/n'); }).listen(1337,"0.0.0.0"); console.log('Server running at http://0.0.0.0:1337/'); url-mapping
生成urlmapping写了一个python脚本:
importhashlib m2 = hashlib.md5() current = "hello world" f = open('./url.map','w') foriinrange(100): m2.update(current) current = m2.hexdigest() f.write('~^/hello/world/'+ current +'//b(/?[^/]*)*/?$/t/;/n') f.close() nginx配置：
server { listen 80; server_name 120.26.138.197; location ^~ /{ if ($new) { proxy_pass http://120.26.138.197:1337$new; break; } return 404; } } abtest
rps测试(request per second)
并发压测使用100000次请求，并发100个用户的方式:
# 不走nginx ab -n100000 -c100 120.26.138.197:1337/ # 走nginx ab -n100000 -c100 120.26.138.197/hello/world/5eb63bbbe01eeed093cb22bb8f5acdc3/
| mapping条目 | 直接访问(rps) | map第一条url(rps) | map最后一条url(rps) | 不存在的url(rps) |
|---|---|---|---|---|
| 100 | 2829.44 | 1819.63 | 1765.25 | 9740.53 |
| 1000 | - | 1816.00 | 1509.52 | 4094.68 |
| 10000 | - | 1813.22 | 514.24 | 658.32 |
| 100000 | - | 1836.02 | 62.40 | 65.80 |
跟预想的一样，mapping的条目确实会对请求效率产生影响。而且几万条的映射在较高并发的情况下已经到了勉强能用的临界了。还好以后mapping的条目不会再增加了，并且论坛的并发很难到100的量级。
tpr测试(time per request)
因为考虑到服务器比较稳定，减少压测总数。同时把并发用户减为1个。
# 不走nginx ab -n1000 -c1 120.26.138.197:1337/ # 走nginx ab -n1000 -c1 120.26.138.197/hello/world/5eb63bbbe01eeed093cb22bb8f5acdc3/
| mapping条目 | 直接访问(ms) | map第一条url(ms) | map最后一条url(ms) | 不存在的url(ms) |
|---|---|---|---|---|
| 100 | 0.690 | 0.922 | 0.933 | 0.507 |
| 1000 | - | 0.925 | 1.043 | 0.648 |
| 10000 | - | 0.921 | 2.340 | 1.915 |
| 100000 | - | 0.926 | 16.321 | 15.469 |
在并发不是很高的时候mapping的条目可以更多。100000个条目大概只会影响整个请求15ms左右，可以忽略不计。如果说150ms的延迟是可以接受的，那么在一个并发不是很高的情况下，mapping最多可以有100w条，还是很多的
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
