はじめに
どうしたら性能テストにおいて本番同等の状況を再現できるだろうか？
性能テストって果てしなくやれちゃう気がするけどどこまでやったらよいの？
本概論では確立されたプロセス・プラクティスに基づいて性能目標設定と計画立案、ワークロード設計や環境構築・負荷ツールなどの準備、性能テストの実施と結果の分析、ボトルネック分析およびチューニングに至るまで「性能テストをきちんとやる」ための標準的なプロセスを紹介します。
- 性能目標設定
- テスト計画策定
- ワークロード設計
- 環境構築
- 性能テスト準備
- 性能テスト実施
- 結果まとめ
本概論を参考に、みなさまのシステムやプロジェクトがおかれた状況にとって最適な性能テストを組み立てて頂ければ幸いです。
1.性能目標設定
性能目標は機能要件（機能一覧）および非機能要件（オンライン性能）をベースに各機能における性能目標を設計します。定義するのは下記の項目です。
- クライアント数（ユーザ数）
- スループット目標（サーバ側からみた同時処理数）
- レスポンス目標（ユーザ側からみた応答時間）
1-1.クライアント数（ユーザ数）
想定する最大ユーザ数を定義します。システムの特性を踏まえ、非アクティブユーザが多い場合はアクティブユーザの割合、ユーザ数の急増が想定される場合はユーザ数増大率を明らかにしたうえで、システムの実態を反映したユーザ数を明らかにします。
1-2.スループット目標
スループット（Throughput）とはある期間において並行可能な処理の数であり、1TPS（Throughput per second）は1秒あたり1要求を処理可能なことをあらわします。スループット上限は、H/Wスペック、OSやミドルウェアの性能限界、アプリケーションのボトルネック等によって決まります。
1-3.レスポンス目標（TAT）
レスポンスタイムは一般的にはクライアントからサーバに応答が返却されるまでの時間です。性能テストという文脈では厳密な意味でのレスポンスタイムとTAT（Turn Around Time）を区別して扱う必要があります。クライアントがサーバへ要求を送り始めてからクライアントへ応答が返り始めるまでの時間をレスポンスタイムといいます。TATはクライアントがサーバへ要求を送り始めてからクライアントに全ての応答が到着するまでの時間です。同様に、クライアントの要求がサーバに最初に到着し始めるまでの時間をレイテンシ（Latency） といいます。本稿におけるレスポンスまたはレスポンスタイムは特に断りがない限りTATを意図するものとします。
🔍TATの目安については D.TATの目安を参照
2.テスト計画策定
性能テストの目的・ゴールを明確化し、目的を達成するためのタスクやスケジュール・体制・役割分担・環境などを定義します。目的・ゴールは特に重要です。性能テストの目的・ゴールが明確になっていないと、「性能に少しでも関連があるあらゆること」を明らかにしようと際限がなくなってしまう可能性があります。開発資源や時間は有限です。システムが達成すべきビジネス目標や、開発フェーズの位置づけを踏まえ、適切な目的・ゴールを決めましょう。このとき参考となるのは「開発計画」「非機能要件定義」などです。
2-1.性能テストの種類
性能テストは下記に示すようにさまざまな種類があります。テスト計画とあわせて実施する内容を選定しましょう。サービスの用途や提供先（一般向け・社内）、ユーザ数増加率、システム構成などの要因を勘案して用途にあった検証方法を選択します。
- ロードテスト（Load testing）
- いわゆる負荷試験。負荷を目標スループットまで徐々に増加させたとき、応答目標を満たしていること、リソース消費やボトルネック有無を検証する。
- 耐久テスト（Soak or endurance testing）
- いわゆる長期稼働試験。長期に渡ってワークロードを掛け続けシステムリソースや挙動に異常が発生しないことを確認する。メモリリークやディスクフラグメンテーションなど、短時間では表出しない性能劣化を確認するために実施する。
- ストレステスト（Stress testing）
- 想定を超えた高い負荷を超えた場合の性能劣化や挙動を検証する。安定性や限界挙動を把握したい場合、アプリケーションに安定した環境の提供が求められる基盤側などで実施する。
- スケーラビリティテスト（Scalability testing）
- 予測されるワークロード増に対しシステムが拡張可能であることを検証する。ロードテストの一種であり、大規模なワークロード、将来業務量の大幅増が想定される場合などに実施する。
2-2.テスト計画
| 検討項目 | 説明 |
|---|---|
| 目的 | システムの性能テストで明らかにしたいことを業務目線で定義します。 （例）全社員からのアクセス集中に耐えられることを検証する。アクセスが集中する早朝出社時の打刻が滞りなく行えること。 |
| ゴール | 性能テストを合格と判断するための基準を定義します。 単に性能目標がクリアできれば良いのか、限界性能などのシステム性能特性を把握したいのか方針を明確にします。 （例1） 1. 性能目標が達成できること。 a) 全社員分のログインが15分間以内に完了できること。 b) 95%のユーザが20秒以内にログイン完了できること。 （例2） 1. 性能目標が達成できること。 2. 性能目標を超えた過負荷時におけるスループット・TATの性能特性を確認する。 |
| 検証方針 |
2-1.性能テストの種類より実施する検証内容を決定します。 ロードテストを基本に、サービスの性質や運用保守体制、将来のビジネスやユーザ数の増加などを見越して「いま」実施しなければならない検証内容を決定します。 |
| タスク分割 | 性能テストに必要なタスクを網羅的に洗い出します。 |
| スケジュール | スケジュールを引き、クリティカルパスを明らかにしましょう。 |
| 体制・役割分担 | テストに関わる関係者やそれぞれの役割を明らかにしましょう。チーム外・他部署・他社との役割分担を明らかにしましょう。 |
| 環境 | テストに用いる環境、構築方法、データ準備方法、共用環境の占有期間、所用コストなどを明らかにします。 |
3.ワークロード設計
実業務でサーバが受ける負荷をワークロード（Workload；負荷）といいます。ワークロードは出来るだけ実業務と同様にする必要があります。ワークロードは要求の送信順や呼び出しの割合、時間あたりの送信頻度などの組み合わせによって構成されます。想定業務シナリオを個別要素（画面・送信順・要求割合・送信頻度）に分解・再構成することでワークロードを設計していきます。
3-1.本番相当のワークロードとは
例えば性能テストで毎回同一画面・同一パラメータで高負荷を掛け目標スループットが達成できたとして、これは十分な検証といえるでしょうか。実運用におけるアクセスパターンは複数画面の組み合わせであり、他画面側に別の負荷要因が存在することが考えられます。毎回同一パラメータというのはどうでしょうか。こうした場合、DBキャッシュ等の効果で見かけ上良い数値が出るものの、I/O負荷が考慮されていないため実業務に耐えられないといった懸念があります。いざ本番を開始したら、検証時より高い負荷が掛かりサーバダウンに見舞われる、といったことになりかねません。本番で実際に想定されるワークロード相当で負荷を掛けることによって、本当のシステムの性能特性を把握することができるのです。
3-2.ワークロード設計の基本
ワークロードの内容によって負荷が掛かるコンポーネントは大きく異なります。CPU、メモリSwap/FullGC、ディスクI/O、Quota/Burstクレジット消尽、NW帯域/レイテンシ、CDNキャッシュヒット/オリジン要求発生、DBキャッシュヒット/IOアクセス発生、Leaderノードボトルネック・・・。システムの各コンポーネントに本番相当の負荷を与えるワークロードの再現を目指しましょう。
ワークロード設計にあたっては、実際の運用シーンで想定される代表的な業務シナリオ、性能問題が想定される業務シナリオを抽出します。それらのシナリオにおいて各機能の利用割合や要求送信頻度などを推定しワークロードを設計していきます。運用実績があるシステムであればアクセスログを元に推測できるかもしれません。そういったものが利用できない場合、例えばショッピングサイトであれば想定CVRなどの手がかりを元にアクセス頻度を推定します。いわゆるフェルミ推定であり厳密な正確さを求めるものではありませんが、仮説の論拠が説明可能であること、論拠の見直しに応じてワークロードに反映できることが大切です。前提条件・想定値・計算式などの論拠を記録しておきましょう。
- 業務シナリオ抽出
- 業務量ピークの抽出（時間帯、5・10日、月末月初、年末年始、決算期、不定期セール…）
- ワークロード設計（要求割合や送信頻度）
- ユーザ数・利用頻度
- 一般サイトであればユーザの回遊パターンやCVRなど
- 業務システムであれば業務フローから推測される画面操作手順
- 画面操作間に挟み込む待機時間など
- 実行条件等の設計（実負荷の再現精度を高める）
- 事前投入するデータ件数やカーディナリティ、データ間の紐付け
- 検索条件（前方一致など）のスキャン範囲（Optimizer Cost）やヒット件数（Pagination）
- CDNキャッシュヒット率（静的コンテンツ配信の場合）
- 画面結果キャッシュ率（静的コンテンツ配信の場合）
- データベースバッファキャッシュ率（動的コンテンツの場合）
4.環境構築
性能テストに用いる環境を準備します。サービスイン前の本番環境を用いる、本番同等の負荷テスト環境を構築する、共用環境を占有するなどによってテスト環境を確保します。テスト実施時は負荷テスト以外のアクセスが発生しないよう、いわゆる「無風状態」とします。性能テスト以外のアクセスが計測結果に含まれてしまうと計測結果の信頼性が揺らいでしまいますし、パフォーマンスの比較やボトルネックの分析も困難となります。
性能テスト環境は自システム環境では完結せず外部呼び出しが含まれることもあります。その場合外部システムに協力をお願いしたり、それが難しい場合はスタブを作成するなどの準備が必要となります。
4-1.データ準備
環境だけでなくデータの準備も必要です。ストレージやデータベース上の大量データは処理効率・処理時間に影響を及ぼすことが多く、実業務で想定されるデータ蓄積件数を再現しておく必要があります。データ件数・量によって作成・転送・展開に長時間を要することがあります。データ作成ツールの作成も視野に入れながら期間に余裕をもって準備を進めましょう。
4-2.環境構築自動化
環境構築は初期段階の準備をもって完了とは限りません。クラスタノード追加時の性能向上を確認したい場合は計測の区切りごとのシステム構成変更・リセットに備え環境構築ツールの利用を検討した方が良いでしょう。この際データストアを構成するノードも構成変更対象に含まれている場合はテスト用データのバックアップ・リストアについても併せて検討が必要です。
5.性能テスト準備
性能テスト開始に向け負荷ツール・シナリオ・分析ツールなどを準備します。負荷ツールを選定し、設計したワークロードをテストシナリオとして実装します。テストシナリオの正常動作を確認し、保存した計測結果を分析してみましょう。必要であれば分析ツールの準備も行います。
5-1.負荷ツール選定
負荷ツールの役割はユーザー端末（複数）を模してサーバーへ要求を送信することです。負荷ツールに求められる要件は性能テストの目的によって異なります。性能目標・テストシナリオ・ワークロード等を踏まえ必要な機能・性能要件を備える負荷ツールを選定しましょう。
負荷ツールの例
- シンプルなHTTP負荷ツール
- ab（Apache Bench）
- Vegeta（Go）
- 複雑なシナリオを記述できる負荷ツール
- JMeter（Javaアプリケーション上でシナリオを作成し.jmxファイルとして保存する）
- Gatling（Scalaでシナリオを記述できる）
- Locust（Pythonでシナリオを記述できる）
- K6（Javascriptでシナリオを記述できる）
- 有償の負荷ツール
- Micro Focus LoadRunner（旧HP）
- パブリッククラウドが提供する分散ロードテスティングサービス
☝参考に、AWSやAzureで提供されている分散ロードテスティングサービスではテストシナリオとしてJMeterの.jmxファイルを使用できます。サービスが想定するトラフィックが高負荷であるといった事情がある場合は分散ロードテスティングサービスの利用も視野に入れてツールを選定するとよいでしょう。
負荷ツールの選定ポイント
- 必要な負荷をかけられる
- 必要な数の仮想端末を同時に起動できる
- 複数プロセス/スレッドで連携して負荷を掛ける
- 複数ノードから負荷を掛けられる
- 開始時にいきなり最大負荷とならないよう設定時間内で徐々に負荷を上げられる（ランプアップ）
- 分散ロードテスティングに対応できる（シナリオファイルがそのまま使える）
- シナリオを作成し実行できる
- 指定回数実行・タイマー・繰り返し実行などのフロー制御
- 要求内容を動的に生成できる
- 要求内容をCSV 等のファイルから読み取れる
- セッションを維持する
- 様々なプロトコル（HTTP/S、MQTT、 TCP、UDP）に対応できる
- 管理
- 負荷送信先のサーバ等を環境変数・設定ファイル等で簡単に切り替えられる
- 実行結果の記録・分析
- 処理時間や応答内容をCSV等のファイルに保存できる
- 統計値を出力できる
- ランプアップ期間や終了間際の期間等を分析対象から除外できる
- スループットやレスポンスタイムの推移をグラフ等に出力できる
5-2.シナリオ作成・動作確認
負荷ツールを選定したら、シナリオを作成し、想定しているワークロードが送信できることを確認します。いきなり送信頻度全開とはいきませんが、送信頻度をセーブした状態等制限付きでいいのでシナリオの正常動作を確認しておきましょう。
5-3.分析の準備
性能テスト実施後は6-5.計測結果分析、E. TATの集計方法についてに記載の結果分析を行います。負荷ツール付属の分析ツールとしてがあればまずそれを使ってみましょう。必要であれば分析ツールを作成します。作成には Excel、Python、R などのお好みのツールを使用します。
6.性能テスト実施
さて、いよいよデータを対象環境に投入し、負荷ツールからサーバに対しワークロードを送信していきます。
6-1.ロードテスト
ロードテストを行う場合は最初は低めのスループット、徐々に性能目標設定で設定した目標スループットに向かってスループットを上げていきましょう。計測中はエラー・システムリソース・ボトルネック有無を監視し、計測が終了したら結果を分析します。分析結果からスループットの伸び、TATが制限以内であること、極端なTAT劣化が発生していないか等を確認していきます。
ピークロードテストであれば目標性能をクリアした時点で検証完了です。目標達成後、尚もスループットを積み増して計測を継続する場合、検証目的に6-2.ストレステストの観点が混じっている、あるいは検証目的がすり替わっている可能性があります。改めて目的を確認してみましょう。
6-2.ストレステスト
ストレステスト・スケーラビリティテストを行う場合はスループットを徐々に積み増しながら、実績スループット・レスポンスタイムをグラフにプロットしていきましょう。計測中はエラー・システムリソース・ボトルネック有無を監視し、計測が終了したら結果を分析します。グラフにプロットしたカーブの傾きからスループットが頭打ちになるポイント、レスポンスタイムが許容値を超えて悪化するポイントなどを分析します。
この際各計測値を比較できるのは環境の状態やチューニングなどの諸条件が同一であることが前提となります。最初は設定スループットを大まかに変更しながらシステムのボトルネック把握・チューニングを行い、変更点が無くなったタイミングで各スループットの計測を行うと良いでしょう（システム設定変更を行うたびに全体の再計測を行うと時間が掛かってしまいます）。
6-3.計測結果の記録
結果の分析に向けて計測結果を記録します。記録すべき項目は下記のようなものです。
a) 負荷ツール・パフォーマンス記録
| 計測項目 | 説明 | 例 |
|---|---|---|
| 開始時間 | 送信を開始した絶対時刻。ミリ秒精度。必要であればマイクロ秒精度 | 2020/01/01 10:00:00.000 |
| 経過時間 | 処理にかかった相対時間。ミリ秒精度。必要であればマイクロ秒精度 | 710 [ms] |
| 処理の種類 | URLパスなど。 | /login |
| 処理結果 | エラーの有無など。 | 200 |
b) H/W・OS等計測メトリクス（例）
| ソースタイプ | メトリクス | 説明 | コマンド例 |
|---|---|---|---|
| CPU | CPU使用率 | CPUを有効に使えている割合。 | top |
| ロードアベレージ | CPU割り当て待ちもしくはI/O待ち中プロセスの数。 | top | |
| コンテキストスイッチ | システムコール呼び出し(ディスクI/O等)やスレッド切り替えで発生するコンテキストスイッチの数。 | vmstat | |
| メモリ | メモリ使用量/空きメモリ | 物理メモリ使用状況。 | vmstat/free |
| スワップ使用量 | 物理メモリからディスクに退避された量。 | vmstat/free | |
| スワップアウト/スワップイン回数 | スワップ発生回数。ディスクはメモリと比べ3～4桁遅いためスワップは極力回避すること。 | vmstat | |
| ディスク | 秒間ディスク帯域 | ディスク転送量を把握する。 | iostat |
| 秒間I/O回数 | ディスクI/O回数を把握する。IOPSスケールアップのための目安となる。 | iostat | |
| I/Oキュー長 | ディスクI/Oスケールアップのための目安となる。 | iostat |
6-4.エラー・ボトルネックの確認
検証中はエラーやボトルネックの有無をこまめにチェックしてください。テストシナリオの作り込み不足やサーバ処理の不具合などが原因であれば修正が必要です。性能目標を大きく超えたスループットのみで発生する場合は一定以上のスループットが流入しないよう流量制御を行うといった対策が考えられます。なお、計測対象に含めるのは正常応答のみです。エラーとなったリクエストは計測対象から除外してください。エラー・ボトルネック確認にあたっては下記項目をチェックします。
- 負荷ツールのログにエラーが記録されていないこと。
- アプリケーションログ・サーバログ等にエラーが記録されていないこと。
- H/W・OS等計測メトリクスにボトルネックとなる値が記録されていないこと。
6-5.計測結果分析
負荷ツール・パフォーマンス記録より、処理実績のスループットおよびTAT（レスポンスタイム）を分析します。TATには一般には%ileを用いることが多いようです。
| 分析項目 | 使用パラメータ | 導出方法 | 集計例 |
|---|---|---|---|
| スループット(秒毎) | 開始時間 | 秒ごとに計測結果を集計する。 （開始時間よりミリ秒以下を切り捨て、同一秒の行数を計数する） |
秒毎スループット： 10:00:00,221TPS 10:00:01,198TPS |
| スループット(全体) | スループット(秒毎) | スループット(秒毎集計)のうち最も高い値をスループット(計測期間全体)とする。 | 全体スループット： 50クライアント,209TPS |
| TAT(秒毎) | 経過時間 | 秒ごとに経過時間を集計する。 🔍集計方法はE.TATの集計方法についてを参照 |
秒毎TAT： 10:00:00,710ms 10:00:01:695ms |
| TAT(全体) | TAT(秒毎) | 全期間の経過時間を集計します。 🔍集計方法はE.TATの集計方法についてを参照 |
全体スループット： 50クライアント,702ms |
スループット・TATをグラフにプロットし、下記観点などを参考にスループット・TATの安定性や目標性能（上限値）における挙動などを確認しましょう。
- 所定クライアント数ごとのスループット・TAT時系列推移
- TAT(秒毎集計)をスループット(秒毎集計)を縦軸に、横軸に時間をプロットすることでスループットとTATの推移を視覚化することができます。
- 所定クライアント数においてスループット・TATが安定していることを確認します。
- クライアント数増に対するスループット・TAT性能特性
- TAT(計測期間全体)とスループット(計測期間全体)を縦軸に、横軸にクライアント数(または入力スループット)をプロットすることで性能特性を視覚化します。
- クライアント数を徐々に増やしていったときの、スループット・TATそれぞれが描くグラフの傾きを確認します。
- 想定する最大クライアント数においてスループットが大きく低下しないこと、TATが大きく悪化しないことを確認します。
6-6.ボトルネック分析・性能チューニング
a) ロードテスト
ロードテストでは性能目標をクリアすれば検証完了です。計測結果が目標性能に満たない場合、H/W・OS等計測メトリクスの分析やプロファイリングツールを用いてボトルネックを特定します。判明したボトルネックを参考に、インフラ設定やアプリケーションコードなどの改善点を究明しましょう。下記事項は性能テストでよくパフォーマンス問題を引き起こす例です。
- 過剰なログファイル書き出し（ログレベルの設定ミスやINFOログの大量出力等）
- 設定ファイルの過剰読み込み（ほぼ変更されない設定ファイルをリクエスト毎読み込んでいる）
- 不必要なスレッド同期処理によってスループットが伸びない
- マシンスペックの不足（コア単体性能、CPU数、メモリ容量、ディスクI/O性能など）
- クラスタノード数の不足
b) ストレステスト
ストレステストでは性能目標を超えた負荷を与えた場合のシステムの挙動やそこに至るまでの性能特性を明らかにします。性能限界が性能目標を下回っている場合はa)ロードテストを参考にボトルネックの特定と改善を実施しましょう。一通りボトルネックが解消した後は下記事項に着目してシステムの性能特性を明らかにします。
- スループットが頭打ちになってから横ばいもしくは微増で安定していること（安定性）
- クライアント数（または入力スループット）それぞれにおける実績スループット・TATが描くカーブを明らかにする（性能特性）
- スループットが低下し始めるポイント、TATが著しく悪化するポイントを見極める（性能限界）
7.結果まとめ
計測・分析の結果を性能テスト結果レポートとして取りまとめます。総論はいわゆるエクゼクティブサマリとなります。検証概要から結果、課題などを簡潔にまとめましょう。各論には検証を行ったシステム構成、計測結果などを事実に沿って淡々と記述します。
総論の執筆にあたって大切なことは、想定読者が誰であるを By Name で念頭におき、想定読者の視座に立ってレポートを執筆することです。自社サービスのCTO、顧客執行役員、顧客システム部長、顧客事業部門DX推進担当役員、、ポジションやロール、経歴によって関心や判断の基準は異なります。想定読者のIT知識・素養に応じてビジネスから語るのか、テクニカル面を全面に打ち出すのか、読み手が受け入れやすいストーリーでの執筆を心がけましょう。
（注：あえて検証結果を曲げる必要はありません。事実を曲げることは無用なトラブルの原因となり禁物です）
記述すべき項目は下記のようなものです。
- 総論
- 検証概要（背景・目的・検証内容・結果サマリ）
- 前提条件および検証観点
- 検証シナリオ
- 検証結果
- 課題と対策案
- 各論
- 各検証シナリオと結果
- 所定クライアント数ごとの検証結果
- 所定クライアント数ごとのスループット・TAT時系列推移
- クライアント数増に対するスループット・TAT性能特性
- H/W・OS等計測メトリクスの時系列推移
- システム構成
- 運用コスト
- 各検証シナリオと結果
おわりに
7章にわたって解説してきましたが、いかがだったでしょうか。ITスキルの中には向き不向きによって習得が難しい類のものもありますが、性能テストは標準的なプロセス・プラクティスが理解できていればトレーニングや反復によって習得することが可能です。また、性能テストのプロセス・プラクティスは環境・言語を問わず応用が効く、いわゆる「ポータブル・スキル」です。これを機会に性能テストに親しみを持って頂けたら幸いです。
Appendix.
A. オンライン性能とは
“オンライン”にも色々ありますが、本稿では「オンライン同期処理」を扱います。オンライン同期処理とは「クライアントからサーバ上の処理を呼び出し、サーバ処理が終了するまでクライアントへの応答が待機する、サーバ処理終了後クライアントへ応答が返る方式」です。その他のオンライン処理として下記のようなものがあります。
- オンライン非同期処理（リモート処理が登録できた段階でクライアントへ応答が返却される方式のこと）
- オンバッチ処理（オンライン処理からバッチ処理を呼び出す方式のこと）
- センタカット処理（バッチ処理からオンライン処理を呼び出す方式のこと。サーバ側部分のみを切り取って見るとオンライン同期処理そのものであるが、系全体としては異なる意味を持つ）
B. ボトルネックとは
ボトルネックとは「瓶（ビン）のすぼまった部分」のことです。システムは多くの構成から要素（CPU、メモリ、ディスク…）されておりそれぞれパフォーマンスに影響を及ぼします。ここで重要なのは「システム全体の性能は最も性能の低い要素に揃う」ということです。瓶を例に取ると、瓶内部を流体が通り抜ける際、最大流量（最大性能）は瓶の最もすぼまった部分の流量に等しくなることから律速あるいはボトルネックと呼ばれています。
OS（カーネルパラメータ）にも同時処理能力の限界が潜んでおり、TCPソケットの再利用待機時間、ファイルディスクリプタ同時利用数などのOSパラメータは意外に閾値が低いためH/W性能としては余裕があるのに性能が伸びないことがあり、この場合チューニングが必要です。Apache のようなWebサーバ、Tomcat のような Webコンテナにはスレッドプールサイズのようなパラメータがあり、このパラメータによって同時処理可能数を制限しています。
上記以外に、アプリケーション側でボトルネックを作り込んでしまうこともあります。例えばマルチスレッドプログラミングではセマフォ・ミューテックス等で複数スレッドによる同時書き込みから共有リソースを保護します。しかしその代償として並走度が犠牲となったりデッドロックが発生することがあります。高い並列性が求められる処理では読み書きロックの分離、CAS（Compare and Swap）などのテクニックを用いて並列性を改善します。
C. 流量制御とは
計算資源（CPU、メモリ、ディスクI/O…）は有限であり、処理能力を大きく超えた負荷が掛かり続けるとシステム全体の応答が著しく劣化したり、OS自体がハングアップ・再起動してしまうといったことがあります。
過負荷抑止などを目的に同時処理数を制限することを流量制御といいます。流量制御はロードバランサーやサイドカープロキシといったネットワークコンポーネントや、アプリケーションサーバやWebサーバなどにもスレッドプールやプロセス数などの流量制御を行う仕組みが備わっていることがあります。
H/Wスペックに余裕があればスレッドプールサイズを増せる可能性がありますし、H/Wスペックが低い、DBサーバの処理能力が低いなどの場合はスレッドプールサイズを絞り込む（減らす）ことによって、過負荷によるサーバダウンやバックエンドDBサーバへの過負荷を抑止することができます。
APサーバを例に取ると、流量制御で設定された同時処理数を超えた要求は待機キューの最後尾に追加され、スレッドプールのワーカースレッドに空きがでたら待機キューの先頭から順に処理がディスパッチされます。FIFOキューのサイズ・待機時間にも上限が設けられておりいずれかを超過した要求はクライアント側にエラーが返却されます。クライアント側にはエラーが返却されますが、流量制御によってサーバに対する過大な要求が流入することが阻止されるためサーバの安定性を保ち続けることができます。
スレッドプールは全ての処理系に存在する訳ではありません。例えば Node.jsではクライアントから受け付けた要求を単一スレッドのイベントループ上で処理する仕組みとなっています。流量制御といった仕組みは存在しないものの、単一スレッドのイベントループで処理を行っているため過大なリクエストを受け付けてしまうということがなく、またI/Oはイベントループとは独立した非同期I/Oの仕組みで処理します。User空間→User空間のコンテキスト・スイッチが不要なためマルチスレッド・モデルと比べてコンテキスト・スイッチのコストが低く済むという利点があります。現にNode.jsはC10K（クライアント数10,000台以上）において高いスケーラビリティを発揮します（別途制約あり）。
D. TATの目安
一般ユーザの離反率は、応答時間が3秒超で直帰率32%上昇、5秒超で直帰率90%上昇ともいわれています。ユーザの体感レスポンスにはサーバ応答時間（TAT）だけでなくWebブラウザのレンダリング時間も含まれます。ユーザの体感レスポンスが目標2秒でありレンダリング時間が0.5秒であるとすると、TATは1.5秒を目標とする必要があります。
留意点として、単純な処理と複雑な処理ではサーバ負荷や処理時間が異なります。全機能3秒以内、、のように画一的にレスポンス目標を決めるのではなく、ユーザ目線を意識しながら処理の複雑さも踏まえて決定しましょう。
E. TATの集計方法について
レスポンスタイム（TAT）の読み取り方は重要です。テストシナリオは一定時間送信し続け、計測されたTAT（複数）を所定の方法で集計します。性能テストでは集計方法として%ile値を用いることが多いので覚えておきましょう。
| 集計方法 | 説明 | 参考 |
|---|---|---|
| 平均値 | 集計値の総和をデータの数で割った値をTATとします（ママ）。 極端に大きな外れ値に引きずられることがあります。 例）レスポンスタイム速報値（平均値）は○○秒（ただし外れ値に引きずられている可能性あり） |
EXCEL AVERAGE関数などを使用する。 |
| 中央値 | データを昇順で並び替え中心の値をTATとします。 実感により近い値が得られます。 例）レスポンスタイム速報値（中央値）は○○秒（ただし外れ値に引きずられている可能性あり） |
EXCEL MEDIAN関数などを使用する。 |
| %ile値 パーセンタイル値 |
計測値を度数分布としたとき指定%ileの累積相対度数に該当する階級の上限値をTATとします。 完全排除が難しい少数の外れ値・極端な値を除外した「大半の計測データ」に基づいて許容可能なレスポンスタイムを決定する場合に用います。性能テストでは%ileを用いることが多いです。 例）計測データの95%はレスポンスタイム○○秒以内を満たす（残り5%は○○秒を満たさないが許容する） |
EXCEL PERCENTILE関数などを使用する。 |
| 最大値 | 計測されたレスポンスタイムのうち最も大きなものです。 1つの外れ値も許されないといったシーンで使用します。 例）全ての計測データはレスポンスタイム○○秒以内を満たす |
EXCEL MAX関数などを使用する。 |
以上