Cloud Run上でのexpressとhonoのパフォーマンス比較

最近、JavaScript界隈の盛り上がりがすごいですね。
zigで作られたJavaScriptのランタイムであるbunは、その便利さ・パフォーマンスの良さから驚くような勢いで広まっています。その一方で新たな軽量WEBフレームワークhonoも非常に注目されています。
honoもbun同様にパフォーマンスが良く、エッジサーバーでの実行を想定しているようで非常に軽量です。Cloudflare Workersを筆頭に、さまざまなランタイム上での動作をサポートしておりbunも対象です。

github.com

話は少し変わりますが、自分はJavaScript(Node.js)でマイクロサービスを作る際はexpressを脳死で選択してきました。
実行環境はプロジェクトの技術選定の制約がありCloud Runになることが多いです。しかし、現在となってはbunにhonoといったexpressよりも軽量でパフォーマンスが良いとされる素晴らしいものが登場しています。
とはいえ、いきなり本番環境に採用するのは難しいため、今回は1つのエビデンスとなるようにCloud Run上で動作するexpressとhonoのパフォーマンスを比較してみたいと思います。合わせてランタイムをbunにした場合のパフォーマンスも計測します。

cloud runの設定

設定値は変更せずにgcloud run deployで設定されるデフォルト値のままです。
ただ、最小インスタンス数は0ではなく1に変更しています。これは可能な限り同じ条件にするために、コールドスタート問題を少しでも回避するためです。今思えば、最大インスタンス数も1で固定したほうが良かったかもしれませんが、これはこれでスケール可能な状態での測定結果ということで自分を納得させました。

サーバーと計測方法について

以下4つの条件でCloud Run上に文字列を返すだけのシンプルなサーバーを用意しました。

$ curl -X GET http://localhost:8080
Hello Hono! 🔥...

express
hono
bun(express)
bun(hono)

デプロイしたコード

4つのサーバーに対してwrkコマンドを使って測定した結果を比較していきます。
本当はwrk2を使いたかったのですが、自分のMacがM1チップ(Apple Silicon)でwrk2がM1チップには対応していなかったので、諦めました...。

github.com

計測結果

同時コネクション数を10にして10秒間、リクエストを送り続けました。
wrk2を使うとリクエスト数も固定できるのですが、先ほど書いたようにM1のためお許しください...。

wrk  -c10 -d10 --latency https://xxxxxx

全体的な結果を見てみると、明らかなパフォーマンスの差はないようです。
合計リクエスト数に差分がある以上、1秒あたりに捌けたリクエスト数を単純に比較するのは難しいですが、レイテンシーの平均値はexpressとhonoを比較してみるとhonoの方がリクエスト数が多いにも関わらず僅かに早いようです。
あくまで平均値ではありますが、honoは標準偏差の値がexpressよりも小さいためexpressと比べると安定しているといえます。

bunを使用することでパフォーマンスが向上するだろうなと予測していましたが、結果は異なりました。
Dockerfileがbunランタイムの有無で共通のものではないので、何か違いが生じたのかもしれません。Cloud Runに関してはbunランタイム化するメリットは現時点ではないようでした。