Skip to content
Measure the performance of actix_web
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
proto
src
.gitignore
Cargo.toml
README.md
build.rs

README.md

actix_web_benchmark

actix_web で性能がでない事案があったため、単体性能を測定してみました. 性能測定には tsung を利用しています.

詳細な条件等(特にカーネル・パラメータなど)は、ブログの方をご覧頂けますと助かります。 Rust の Web Framework, actix_web のパフォーマンスをとことん測定する

前提条件

Dependencies

  • Rust >= 1.26.1
  • actix_web >= 0.7.4
  • grpc-rust = 0.4.0 もしくは grpc-rs >= 0.3.0

Server spec

  • VM: GCP n1-standard-4
  • CPU: 4 cores
  • MEM: 15 GB
  • OS: Ubuntu 16.4

Results

1. 固定文字列

path: /health

結果

送信req/sec speed(ms) rps 備考
1,000 0.400 955.13
5,000 0.330 4744.52
10,000 0.891 8657.37 ここまでは1req < 1ms
12,000 8.89 9631.00 10,000req/s と比べて10倍遅い
14,000 100.0 10457.52 厳しい

12,000 req/sec くらいがこのスペックでの許容限界と考えて良さそうです.

2. 100ms スリープ

path: /sleep

結果

送信req/sec speed(ms) rps 備考
1,000 100.0 928.87 100ms スリープの理論レスポンスタイム
5,000 100.0 4645.31 上に同じ
10,000 100.0 8341.21 上に同じ
12,000 160.0 9093.34 100ms では返せなくなってきた
14,000 360.0 9898.09

/health と同じく、 12,000 req/sec くらいが限界.

3. Future 内で 100ms スリープ

path: /f_sleep

結果

送信req/sec speed(ms) rps 備考
1,000 100.0 939.11 100ms スリープの理論レスポンスタイム
5,000 100.0 4670.44 上に同じ
10,000 100.0 8356.93 上に同じ
12,000 200.0 9197.38 100ms では返せなくなってきた
14,000 500.0 9814.52

こちらも /sleep とほぼ同じ結果でした.

4. Atomic カウンター

path: /count

結果

送信req/sec speed(ms) rps 備考
1,000 0.419 921.40
5,000 0.344 4615.94
10,000 0.883 8329.02
12,000 3.86 9407.66
14,000 210.0 10122.08 厳しい

ほぼ /health と同じ結果です.
Atomic 操作のオーバーヘッドは思ったよりずっと少ないようでした.

5. Actor に送信したメッセージのレスポンスを待つ

path: /send_wait

結果

送信req/sec speed(ms) rps 備考
10 2630.0 9.83

これは話になりませんでした.

6. Future 内で Actor に送信したメッセージのレスポンスを待つ

path: /fsend_wait

結果

送信req/sec speed(ms) rps 備考
10 3150.0 9.94

Future にしてみてもそう変わりはありませんでした.

7. Actor に送信したメッセージ を別スレッドで待ち受ける

path: /send_nowait

結果

送信req/sec speed(ms) rps 備考
1,000 0.409 931.27
5,000 0.356 4629.57
10,000 0.948 8384.00
12,000 27.87 9358.64
14,000 230.0 10176.96

さすがに、別スレッドで待ち受ければ、 /health と同程度のパフォーマンスがでます.

8. 同期的 gRPC 通信

path: /grpc_wait

gRPC サーバは 数ms〜数百msの間でレスポンスを返します.

結果

送信req/sec speed(ms) rps 備考
200 10.75 186.29
400 66.47 368.18 このあたりで限界のよう
500 9,770.0 309.18
1,000 16,170.0 383.98

話になりませんね.

9. 非同期 gRPC 通信

path: /fgrpc_wait

gRPC サーバは 数ms〜数百msの間でレスポンスを返します.

結果

送信req/sec speed(ms) rps 備考
200 11.64 183.06
400 71.44 371.11 このあたりで限界のよう
500 24,370.0 309.11
1,000 15,530.0 382.12

同期的 gRPC 通信 と同様の結果です。

10. gRPC クライアントの都度生成

path: /grpc_per

gRPC サーバは 数ms〜数百msの間でレスポンスを返します.

結果

送信req/sec speed(ms) rps 備考
500 7.82 463.78
800 18.16 719.83
1,000 43.71 932.43
1,200 490.0 967.82

リクエストごとに都度 gRPC クライアントの生成を行うようにしたら、パフォーマンスが超絶向上しました.

You can’t perform that action at this time.