サーバースペック・ランタイム・DB構成を入れると、到達できる最大TPSとボトルネックになる箇所を推定します。
土台にあるのは リトルの法則、すなわち「同時処理数 = TPS × 応答時間」という関係式です。逆に解けば、ある資源の同時処理上限を応答時間で割った値が、その資源が捌けるTPSの上限になります。
この計算を 資源ごとに個別に 行います。CPU、ソケット、スレッドプール、DBコネクションプールのそれぞれに固有の上限TPSがあります。
そして 最も低い値がシステム全体の上限 になり、その資源がボトルネックとして表示されます。他をいくら増強しても、この一点を動かさない限り全体のTPSは1も増えません。
たとえばCPUの上限は「コア数 ÷ 1リクエストあたりのCPU演算時間 × サーバー台数」です。4コア・演算2msなら1台で毎秒2,000件、これが理論上の天井になります。
スレッド・パー・リクエスト(従来のSpring MVCなど)は、外部I/Oを待っている間もスレッドを占有し続けます。そのためスレッドプールが真っ先に枯渇し、CPUがまだ暇なのにTPSが頭打ちになります。
この場合の上限は「スレッドプール数 ÷ 総処理時間 × 台数」です。総処理時間にはCPU演算だけでなくDB待ちも外部API待ちも含まれる点が重要で、待ち時間が長いほどプールの回転が落ちます。
Virtual Thread・Go・Node.js はI/O待ちでスレッドを掴まないため、この制約自体が消えます。そのため同じハードウェアでもCPUやソケットが先に限界を迎えるまで伸びます。
ただし Node.jsには別の注意点 があります。1リクエストのCPU演算が20ms以上になるとイベントループを塞ぐ危険があり、このツールは該当する設定で警告を出します。重い計算を単一ループ上で回す構成は避けるべきという意味です。
キャッシュに当たった読み取りリクエストは DBまで到達しません。したがってDBコネクションプールにかかる負荷はその分だけ純粋に減ります。
計算上は「実効読み取り比率 = 読み取り比率 ×(1 − キャッシュヒット率)」として扱われます。読み取り80%・ヒット率50%なら、DBに届く読み取りは全体の40%まで下がる計算です。
だから 読み取り比率が高いサービスほどキャッシュの効果が大きく なります。書き込み中心のワークロードではヒット率をいくら上げてもマスターへの負荷は変わりません。
Master/Slave構成を選ぶと、書き込みはマスターへ、実効読み取りはレプリカ群へ振り分けられ、それぞれ別々に上限TPSが計算されます。レプリカを増やして効くのは読み取り側だけです。
MQを有効にすると、遅い外部API呼び出しをキューへ委譲したものとして扱い、リクエスト処理経路から外部遅延を取り除きます。代わりにキューへの積み込みコストとして5msだけを計上します。
外部APIの遅延が300msあった構成なら、1リクエストの総処理時間が劇的に短くなります。スレッドを占有し続けるモデルではこの差がそのままスレッド回転率になるため、効果が最も派手に現れます。
もうひとつの効果は 過負荷時の安全性 です。処理能力を超えたトラフィックはキューに保管されるため、サーバー側でリクエストが滞留してメモリを食い潰す事態を避けられます。
MQを使わずアプリ側がボトルネックになっている場合、超過分は待機コネクションとしてメモリに積み上がります。このツールはその分を上乗せして計算し、RAMを超えればOOMとして表示します。
処理中のリクエスト1件あたり 1MB のメモリを占有するという前提で見積もっています。同時処理数が増えれば、そのままメモリ使用量に跳ね返ります。
これに基礎メモリが加算されます。スレッドモデルでは「512MB + スレッド数 × 1MB」、非同期モデルでは「CPUコア数 × 100MB」を目安としています。スレッド数を無闇に増やすとメモリだけ食う理由がここにあります。
使用量が搭載RAMを超えると、ボトルネックは資源の種類にかかわらず OOM に切り替わります。TPS上限には余裕があってもメモリで先に落ちる、という現実的な失敗パターンです。
スレッドプールを増やせばTPSは上がりますが、同時にメモリも増えます。この2つのトレードオフを数字で見られるのがこのツールの目的です。
改善で最も無駄が多いのは、ボトルネックではない資源を増強すること です。CPUが天井になっている状態でDBコネクションプールを倍にしても、最大TPSは1件も増えません。
スレッドプールがボトルネックなら、プールを増やすかランタイムを非同期モデルへ移すかの二択です。ただしプールを増やせばメモリも増えるので、OOM側の余裕を必ず同時に確認してください。
DBがボトルネックなら、コネクションプールの拡張、キャッシュヒット率の向上、読み取りレプリカの追加という順で効果を検討します。読み取り主体のサービスならキャッシュが最も費用対効果に優れます。
CPUがボトルネックなら、サーバー台数を増やす水平スケールか、1リクエストあたりの演算時間そのものを短くするかです。後者はコード改善の領域で、成功すれば追加費用なしに上限が上がります。
解消すると 必ず次のボトルネックが現れます。 これは失敗ではなく正常な過程で、どこまで投資すれば目標TPSに届くかを段階的に見積もるのがこのツールの使い方です。
これは 計算だけのシミュレーション です。実際のサーバーへ通信は一切行わず、すべての数値はブラウザ内で算出されます。
モデルは意図的に単純化されています。GCの停止時間、ネットワーク帯域、ディスクI/O、スレッド切り替えのコスト、DBのロック競合やインデックスの効き方は反映されていません。
リクエストごとの処理時間のばらつきも考慮していません。実システムでは平均値ではなくテール遅延(p99)が体感を決めるため、実測との差はここで生まれやすくなります。
したがってこの結果は スペック見積もりの出発点や増設判断の当たりを付けるための道具 として使ってください。最終的な確認はk6やJMeterなどによる負荷テストで行う必要があります。
同時接続が増えたとき、待ち行列と応答時間がどう伸びるかを直感的に見るためのシミュレーターです。
いいえ。計算だけのシミュレーションで、外部に通信は行いません。
待ち行列理論の基本的な考え方に沿って、到着率と処理率から待ち時間を求めています。