arimitsu-koichiro/rust_fw_research.md

## rust_fw_research.md

      
    Raw
  

              rust_fw_research.md
            
          
    結論

秒間10000/req以上かけてもfd掴みっぱなし等の現象は発現しなかった。
検証環境

benchmark server(vCPU:2, mem:1.8GB): http://34.85.8.96:8888/
stresser server(vCPU:8, mem:7.2GB) & result: http://34.85.7.57:8000/
検証アプリ

source: https://github.com/sxend/examplehttp
benchmark server ( http://34.85.8.96:8888/ )みたいなレスポンスを返すserverを各FWで実装した。
(実行時に使用するワーカースレッドは4つになるようにした)
actix
hyper
nodejs
tokio

一番下の tokio は httparse を用いて自前で簡易HTTP serverを
実装したもの。

HTTP(プロトコル)全てを実装しているわけでは無い。
benchmark serverのカーネルパラメータは以下のようにした。
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 2

検証アプリ(プロセス)のfdの上限だが、

stresser serverのip_local_port_rangeは
net.ipv4.ip_local_port_range = 32768	60999

のため、28231 + αってことで30000とした。
ベンチマーク記録

stresser serverに

<FW名>-<最大req/sec>-<timestamp>

という形式で保存されている。
エラーが起きなかった最大スループット記録
http://34.85.7.57:8000/hyper/hyper-17000-1549509074130/
http://34.85.7.57:8000/actix/actix-16000-1549507926508/
http://34.85.7.57:8000/tokio/tokio-20000-1549506024698/

当然だが
自前実装(不完全HTTP) > hyper > actix-web
となった。

失敗したケースは処理が詰まってgatling側でレスポンスタイムアウトになったケースばかりで、too many open file 等は確認されなかった。
最後に

actix-webはactix上に構築されているのでその分オーバヘッドがあり、内部的にもhyperと同じくhttparseを使用している為不利なのは確かでそのままの結果になった。
httparseのissues(seanmonstar/httparse#18) でも述べられているが、

httparseはparseのたびにbyte配列を最初から最後までparseし直さないといけないので効率が悪い。

これを改善したライブラリを作るか、httparseを改善すればもっと早いFWが作れるかも?と思った。