ホーム›技術記事›トランザクション処理能力

スループットMIPSボトルネックネットワーク帯域TPSCPU性能設計

SYSTEM PERFORMANCE / THROUGHPUT

トランザクション処理能力を図解｜MIPS・通信速度・ボトルネックとスループット

「検索は高速なのに、利用者が増えると遅くなる」現象を、CPU・通信の関係と具体的な数値から理解します。

01｜身近な具体例：検索画面のどこが遅くなりますか

Next.jsとSupabaseで、予約一覧や商品を検索するWebアプリを作ったとします。利用者が「検索」を押すと、サーバーが検索処理を行い、結果のデータがネットワークを通ってブラウザへ返ります。データベースの検索が高速でも、画像や大量の行を返すと通信が混み合う場合があります。

ブラウザ

検索語を入力し、HTTPリクエストを送る

サーバー／DB

条件を評価して結果をつくる

ネットワーク

結果のバイト列を利用者に届ける

Supabaseを使うアプリを題材とした概念図です。ブラウザがSupabase APIを直接呼ぶ構成など、実際の経路は実装によって異なります。

大量の検索要求が来たとき、サーバーが処理できる速度と、回線が結果を運べる速度の両方に限界があります。システム全体は、最も能力の低い工程に引っ張られます。

02｜最初に覚えるのは「レイテンシ」と「スループット」の違い

指標・英語	意味	身近な例
レイテンシ（latency）	1件が完了するまでに待つ時間	検索結果が画面に出るまで0.2秒
スループット（throughput）	一定時間内に処理できた件数や量	1秒間に50件の検索が完了
TPS（Transactions Per Second）	毎秒のトランザクション数	毎秒に確定した注文が25件
ボトルネック（bottleneck）	全体の処理量を制限する工程	CPUは余裕でも回線が満杯

03｜CPUが「命令を実行する」とは

CPU（Central Processing Unit：中央処理装置）はプログラムの機械語命令を実行します。検索処理では、データの読み込み、比較、分岐、計算など多くの命令が必要です。ここでは検索1件につき平均100万命令を実行すると仮定します。

命令を取得

実行する処理を取り出す

比較・計算

検索条件などを評価する

結果を準備

検索結果を返せる状態にする

CPUの仕事を単純化した図です。実際のDB処理ではI/O待ちやキャッシュも性能に影響します。

04｜MIPSという単位を読み解きます

MIPSは Million Instructions Per Second（ミリオン・インストラクションズ・パー・セカンド）の略で、毎秒何百万個の命令を実行するかを表す指標です。1 MIPS＝毎秒100万命令、100 MIPS＝毎秒1億命令です。

05｜ビットとバイトは8倍違います

ネットワークの通信速度は通常 bps（bits per second：ビット毎秒）で表し、ファイルサイズやAPIのデータ量はバイト（Byte）で表します。1バイト＝8ビットなので、単位を合わせる必要があります。

表記	読み方・意味	換算
bit／b	ビット：0または1の情報単位	8bit＝1Byte
Byte／B	バイト：データの大きさの単位	1B＝8bit
Mbps	メガビット毎秒	80Mbps＝80,000,000bit/秒
MB/s	メガバイト毎秒	80Mbps÷8＝10MB/s

06｜1件あたりの転送量を確認します

問題のモデルでは検索1件につき20万バイトを転送します。ビットに換算すると20万×8＝160万ビットです。回線の最大転送速度は8,000万ビット／秒なので、「8,000万÷160万＝50件／秒」です。

07｜サーバーと回線は別々に能力を求めます

工程	1秒に使える資源	1件あたりに必要な資源	理論上の件数
CPU	100×10⁶命令	1×10⁶命令	100件／秒
ネットワーク	8×10⁷ビット	2×10⁵バイト×8＝1.6×10⁶ビット	50件／秒

両工程を通過する必要があるので、100と50を足すのではありません。min（100, 50）＝50件／秒が答えです。余っているCPU能力だけでは、遅い回線の代わりにはなれません。

08｜なぜ処理能力を足してはいけないのでしょうか

製品の検品が毎分100個でも、配送車が毎分50個しか運べなければ、毎分50個しか出荷できません。検索システムも同じです。CPUと通信は異なる工程を担当しており、合計150件になるわけではありません。

検索受付

1秒に100件処理可能

結果の生成

CPUが100件を準備できる

結果の転送

回線は50件しか運べない

処理経路に直列に並ぶ工程の能力は、最小値で制限されます。

09｜式を一般化すると別の場面にも使えます

CPUの毎秒命令実行数を C、1件あたりの命令数を I、回線の毎秒ビット数を N、1件あたりのバイト数を D とすると、CPU側の能力は C÷I、回線側の能力は N÷(8D) です。

CPU能力 = C / I
通信能力 = N / (8 × D)
全体の処理能力 = min(C / I, N / (8 × D))

この式は、各検索が平均的に同じ資源を消費し、CPU処理と通信の双方が安定して流れる理想化したモデルです。通信時間とCPU時間を単純に足して件数上限を求めるモデルとは、前提が異なります。

10｜実際に数字を変えてボトルネックを探します

CPUのMIPS、検索に必要な命令数、回線Mbps、返すバイト数を変えてみましょう。回線だけ2倍にするとボトルネックは移りますか。サーバーを2台に増やすとどうなりますか。

操作ラボ｜CPUと回線のどちらが先に限界を迎えますか

数値を変更すると、1秒に何件処理できるかを再計算します。これは問題と同様にCPUとネットワークの能力だけで決まる単純化モデルです。

CPU性能（MIPS）1検索の命令数（百万命令）通信帯域（Mbps）1検索の通信量（バイト）毎秒の到着要求（件）CPUサーバー台数（単純な均等分散）

CPU側の上限

100件/秒

ネットワーク側の上限

50件/秒

システムの上限

50件/秒

CPU100 件/秒

ネットワーク50 件/秒

ボトルネック：ネットワーク

到着 40 件/秒に対して、処理 40 件/秒。この単純化モデルでは能力の範囲内です。

待ち行列の増加（到着率が一定の場合）

10s

実運用では通信オーバーヘッド、DB、キャッシュ、同時実行制御、遅延、キュー容量などが加わります。MIPSが高くてもアプリケーション性能を直接保証しません。

11｜Next.js・Supabaseの検索では何が詰まりますか

実アプリでは単にCPUと回線だけでなく、Postgresのクエリ、インデックス、ストレージI/O、認証、外部API、コネクション数、サーバーレス関数の制約、ブラウザの描画などが関わります。今回の問題は、それらを省いたモデルです。

Next.js

入力・通信・画面描画

Supabase／DB

検索条件・インデックス・応答生成

配信

JSONのサイズ・回線帯域・遅延

典型的な観測ポイント。Supabaseの内部の正確な構成・性能値を表す図ではありません。

12｜改善策1：送るデータ量を減らします

回線がボトルネックの場合、1件あたり20万バイトを10万バイトに減らせれば、同じ80Mbpsでも通信能力の上限は100件／秒に上がります。必要な列だけ選ぶ、ページネーションを使う、圧縮する、画像を適切に配信するなどが有効です。

// 必要な列だけ取得し、1ページ20件に制限する例
const { data, error } = await supabase
  .from("reservations")
  .select("id, start_time, status")
  .range(0, 19);
if (error) throw error;

13｜改善策2：CPUやDBの処理を軽くします

CPUがボトルネックなら、効率の悪い処理の見直し、DBインデックス、不要なループの削除、キャッシュなどが候補です。ただし、CPUを2倍にしても回線が先に限界へ達していれば、全体の処理件数は増えません。増強するべき資源は、現在のボトルネックに依存します。

14｜待ち行列：限界以上の要求が来るとどうなるのでしょうか

回線が50件／秒までしか処理できないところへ、毎秒80件が到着すると、理論上は毎秒30件ずつ待ち行列が増えます。十分なバッファがなければタイムアウトやエラーも起こります。待ち時間が増えるため、処理能力と利用者体験は分けて監視する必要があります。

15｜TPSとDBトランザクションの意味を区別します

トランザクションは、DBではBEGINからCOMMITまたはROLLBACKまでの整合性を保つ処理単位を指します。一方、性能指標のTPSはベンチマークなどで定義された処理単位の毎秒実行数です。検索APIの1回とDBトランザクション1回が必ず一致するわけではありません。

16｜ネットワークは帯域だけでは決まりません

帯域（bandwidth）は一定時間に運べる情報量の上限に関わります。遅延（latency）、往復時間RTT（Round-Trip Time）、パケット損失、プロトコルの制御なども実際の転送性能へ影響します。80Mbpsと書いてあっても、アプリケーションの有効データが常に80Mbpsで流れるわけではありません。

17｜システム性能を観測する指標

指標	観測するもの	判断の手掛かり
RPS（Requests Per Second）	毎秒のHTTP要求数	API全体の負荷
TPS	毎秒の定義されたトランザクション数	業務処理の能力
p95応答時間	95%のリクエストが収まる時間	遅い要求の傾向
CPU使用率	CPUの稼働状況	CPUの余裕・過負荷
ネットワーク転送量	1秒あたりのビット・バイト数	回線や配信の負荷
エラー率	失敗した要求の割合	過負荷や障害の兆候

18｜まとめ：全体の上限は最も狭い場所で決まります

CPU 100MIPS、検索1件100万命令ならCPU側は100件／秒。回線80Mbps、検索1件20万バイトなら通信側は50件／秒です。全体は小さい方の50件／秒で制限されます。どちらの性能も、同じ「件／秒」という単位に換算してから比較することがポイントです。

実務ではまずアプリの処理経路をノード図に描き、各工程の能力・時間・エラーを測ることから始めます。そうすれば、CPUを増やすべきか、転送量を減らすべきか、DBを改善すべきかを根拠をもって考えられます。