分かったこと

待受けの相手をするコストは、ほとんど無かった

測る前は「待受けを何本も抱えると重くなる」と思っていたが、10 本ぶら下げても node で 2.08 MB、bun で 5.93 MB しか増えなかった。1 本あたり 0.21 MB ・ 0.59 MB である。

常駐コストを決めているのは、ぶら下がっている本数ではなく処理系そのものだった。そこで 22.9 MB の差が付いている。

速さを決めているのは処理系ではない

say の 3.1 ms は読み取りの 10 倍かかっている。WAL に同期で書いているためで、ここを速くしたいなら処理系ではなく書き方を変えることになる。ただし人が待つ時間としては十分短い。

どちらのメモリを見るか

実メモリだけを見て「bun のほうが軽い」と決めると読み違える。確保量では逆に 4.3 倍を抱えている。

CLI を測ったときも同じ傾向だった。bun は実メモリ 25.59 MB で C# と並びながら、確保量は 108.43 MB で 5 実装のうち最大だった。処理系の癖であり、サーバーでも CLI でも変わらない。

待受けの相手としてのメモリ

待受けを 0 ・ 1 ・ 5 ・ 10 本ぶら下げ、それぞれで落ち着くのを待ってから 3 秒ぶんを平均した。

確保量では逆になる

なぜ伸びないか

待受けは /api/poll にぶら下がったまま何もしない。サーバー側が抱えるのは TCP の接続 1 本と、いつ起こすかを覚えておく分だけである。発言が来るまで処理は動かない。

1 本あたり node 0.24 MB ・ bun 0.58 MB。bun のほうが 1 本を重く持つが、実メモリでは出発点の差が大きいので順位は変わらない。

どこで追いつかれるか

実メモリの伸び方がそのまま続くとして解くと、66 本で交差する。

node   54.52 + 0.24 × n
bun    31.99 + 0.58 × n
                       → n ≒ 66

待受けは 1 プロジェクトにつき 1 本と決めている。66 本が並ぶことは無い。

say と recent

人が待つのはここである。say は 200 回、recent(/api/history)は件数を変えて 200 回ずつ測った。

単位は ms。

書くのは読むより 10 倍かかる

say 3.1 ms に対して recent 50 件が 0.33 ms。差は SQLite に同期で書いているぶんである。読むほうはメモリの上で済むことが多い。

件数を 50 から 500 へ 10 倍にしても、かかる時間は 3 倍にしかならない。問い合わせ自体の手間が大きく、件数はその上に乗るだけだからである。

待受けを抱えたままでも遅くならない

別のルームへ打って、起こす処理が混ざらないようにして測った。抱えているだけでは何も起きない。

配信の遅れ

say を打ってから、ぶら下がっている待受けが全員返るまでを測った。人から見ると「送った」から「相手に出た」までである。

読み取れること

本数に比例する。1 本増えるごとに 2.2 〜 2.6 ms。待受けを 1 本ずつ起こし、その相手ごとに返すものを作っているためである。

最初の 1 本に 5.6 ms かかるのは、say 自体の 3.1 ms が含まれているから。書き終えてから起こしにいく。

測り方

使ったもの

メモリは、外からではなく中から測る

別のプロセスのメモリを測る手立ては OS ごとに違う。Windows は tasklist ・ WMI、Mac ・ Linux は ps になる。Mac ・ Linux にも展開するので、測り方が OS で分かれる形は持ちたくない。

そこで サーバーを子プロセスの中で import し、そのプロセス自身に process.memoryUsage() を呼ばせた。node でも bun でも、どの OS でも同じ 1 本のコードで済む。

// server-probe.mjs
await import(pathToFileURL(join(root, 'src', 'server', 'main.mjs')).href);
process.stdout.write('__READY__\n');
setInterval(() => {
	const m = process.memoryUsage();
	process.stdout.write(`__MEM__ ${m.rss} ${m.heapUsed} ${m.heapTotal} ${m.external}\n`);
}, 250);

親は標準出力の印つきの行だけを拾う。サーバー自身のログも同じ出力に混ざるので、印で選り分けている。

本番に触らない作りにする

測る手順

この測定の限界

• 確保量は Windows でしか測れない。実メモリは process.memoryUsage() でどの OS でも測れるが、確保量は Get-Process に聞いている。Mac ・ Linux では別の聞き方が要る
• 1 台の Windows で測った。Mac ・ Linux では変わりうる
• DB は空から 600 件まで。本番の量では recent の数字が変わる
• 待受けは同じマシンから張った。すべてループバックで、実際の経路とは違う

測り直しになった話

気づいた形

書くのも読むのも、50 件も 500 件も同じ値になることはない。どれかが全部を律速している。

切り分け

何もしない HTTP サーバーを立てて、同じやり方で測った。

node の fetch だけが遅かった。最小は 0.36 ms まで下がるので、返せないのではなく待たされている。Windows の既定のタイマー解像度 15.6 ms と一致する。

直した形

ベンチマークの側を node:http の http.request(keepAlive つき)に替えた。node で走らせても bun で走らせても同じ数字が出るようになり、そこで初めて処理系の差が見えた。

結論は変わらなかったが、「差が無い」と「差が見えない」は別のことである。前者は測ってから言える。

持ち帰り

再現の手順は tests/http-client-latency.test.mjs に置いた。速さの下限は決めていない。手段によって結果が変わったときだけ落ち、往復の時間は毎回数字として出る。課題が直ったかはその数字で見る。