摘要：每個(gè)請求來的時(shí)候都會(huì)先去看看中有沒有，即使使用的是的方式也不免會(huì)讓我對它的性能產(chǎn)生一些擔(dān)憂，所以性能測試就必須要來一發(fā)了。注也在阿里云執(zhí)行只要是為了在一個(gè)數(shù)據(jù)中心降低網(wǎng)絡(luò)延遲。測試因?yàn)榭紤]到服務(wù)器比較穩(wěn)定，減少壓測總數(shù)。

最近我操刀了leetcode的論壇遷移，整個(gè)過程持續(xù)了幾周的時(shí)間，總算暫時(shí)告了一個(gè)段落。常使用leetcode論壇的用戶應(yīng)該已經(jīng)發(fā)現(xiàn)論壇已經(jīng)大變樣了吧~

期間遇到了不少坑坑洼洼，將來也還會(huì)有好多問題等待去一一解決。關(guān)于這個(gè)遷移過程中的收貨，這篇文章中就不細(xì)說了，有時(shí)間再另開一篇博文。這篇文章主要關(guān)注在url-mapping以及它的性能問題。

問：url-mapping的問題從何而來呢？

舊的論壇和新的論壇是兩個(gè)不同的discuss框架。前者是phpbb，現(xiàn)在是nodebb。兩者的 url routing 完全不一樣，比如說同一個(gè)topic，在原來的url是 http://hostname/discuss//，在新的論壇中是 http://hostname/topic//（這里就不討論兩者甚至連topic_id都不一樣的問題了）。

而在廣袤的互聯(lián)網(wǎng)海洋中，舊論壇的url可能到處都存在。我們不希望在論壇遷移后，用戶點(diǎn)那些鏈接就失效了。我們希望的是用戶訪問舊的url可以被重定向到新論壇的某個(gè)地址。所以就產(chǎn)生了url-mapping的問題。

感謝nodebb-plugin-import提供了數(shù)據(jù)遷移以后自動(dòng)生成url-mapping的方式，省了我自己寫腳本生成這些mapping的時(shí)間。每一條mapping大致是這樣的：

~^/discuss/questions/oj/add-two-numbers(?[^/]*)*/?$  /category/10/add-two-numbers;

其中的slug和id的mapping是由插件生成的。regular expression是為了匹配url中如果有param添加的。

官方文檔的demo可能對于剛想上手的同學(xué)來說不是那么友好，還是直接看現(xiàn)成的配置學(xué)得快：

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規(guī)則匹配中，$new值不為空，說明當(dāng)前要訪問的url已經(jīng)在http模塊的mapping文件中匹配到了，這個(gè)時(shí)候就不走各種location模塊了，直接rewrite成新的地址。注:這里要是做成proxy_pass也行，后面的測試中就采用了proxy_pass。但線上的環(huán)境，擔(dān)心nginx的壓力太大了，就采用了rewrite方式給它減減壓。

考慮到mapping的條目有點(diǎn)多，幾萬量級(jí)，又都是正則匹配。每個(gè)請求來的時(shí)候都會(huì)先去看看mapping中有沒有，即使mapping使用的是hash的方式也不免會(huì)讓我對它的性能產(chǎn)生一些擔(dān)憂，所以性能測試就必須要來一發(fā)了。

測試方案：

在新機(jī)器上跑helloworld

自動(dòng)生成隨機(jī)100個(gè)url-mapping，都重定向到helloworld

使用abtest分別對helloworld和隨機(jī)url作壓測

增大url-mapping的條目，重復(fù)1,2

臨時(shí)租了兩臺(tái)阿里云服務(wù)器(因?yàn)槭桥R時(shí)的，所以我也就不在意在后文暴露ip了)，配置都是：1核，2048M內(nèi)存，40G硬盤。一臺(tái)用作nginx和helloworld程序，一臺(tái)專門做abtest。

注：abtest也在阿里云執(zhí)行只要是為了在一個(gè)數(shù)據(jù)中心降低網(wǎng)絡(luò)延遲。最后發(fā)現(xiàn)效果真不錯(cuò)，rps從100多直接飆升到2700多。

采用了nodejs的helloworld：

var http = require("http");
var i = 0;
http.createServer(function (req, res) {
  console.log(i++);
  res.writeHead(200, {"Content-Type": "text/plain"});
  res.end("Hello World
");
}).listen(1337, "0.0.0.0");
console.log("Server running at http://0.0.0.0:1337/");

生成urlmapping寫了一個(gè)python腳本：

import hashlib

m2 = hashlib.md5()
current = "hello world"
f = open("./url.map", "w")

for i in range(100):
    m2.update(current)
    current = m2.hexdigest()
    f.write("~^/hello/world/" + current + "(?[^/]*)*/?$	/;
")

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;
  }
}

rps測試(request per second)：并發(fā)壓測使用100000次請求，并發(fā)100個(gè)用戶的方式。

# 不走nginx
ab -n100000 -c100 120.26.138.197:1337/
# 走nginx
ab -n100000 -c100 120.26.138.197/hello/world/5eb63bbbe01eeed093cb22bb8f5acdc3/

跟預(yù)想的一樣，mapping的條目確實(shí)會(huì)對請求效率產(chǎn)生影響。而且?guī)兹f條的映射在較高并發(fā)的情況下已經(jīng)到了勉強(qiáng)能用的臨界了。還好以后mapping的條目不會(huì)再增加了，并且論壇的并發(fā)很難到100的量級(jí)。

tpr測試(time per request)：因?yàn)榭紤]到服務(wù)器比較穩(wěn)定，減少壓測總數(shù)。同時(shí)把并發(fā)用戶減為1個(gè)。

# 不走nginx
ab -n1000 -c1 120.26.138.197:1337/
# 走nginx
ab -n1000 -c1 120.26.138.197/hello/world/5eb63bbbe01eeed093cb22bb8f5acdc3/

在并發(fā)不是很高的時(shí)候mapping的條目可以更多。100000個(gè)條目大概只會(huì)影響整個(gè)請求15ms左右，可以忽略不計(jì)。如果說150ms的延遲是可以接受的，那么在一個(gè)并發(fā)不是很高的情況下，mapping最多可以有100w條，還是很多的。

壓測的url請求并不隨機(jī)

所有的url都被重定向到一個(gè)地方。不過從結(jié)果來看，nginx確實(shí)是根據(jù)條目一個(gè)個(gè)請求的。這點(diǎn)倒沒有什么影響

沒有測試http://hostname/path?param=xxx這樣類型的url