回答:
このテーマに関するウィキペディアの記事を読むことから始めます。
要するに、スケーラビリティとは、リソースを追加することでシステムパフォーマンスがどのように向上するか、あるいは、負荷が増加するにつれてリソース使用率がどのように増加するかです。たとえば、応答時間が0.3秒を超えるまで、サイトは何人の同時ユーザーを処理できますか？使用可能なRAM /ディスク/ CPU /などを2倍にした後の同じ質問。おそらく、アプリケーション内部の知識を使用して、どのパラメーターをチェックする価値があるかを判断できます。
サーバーマシンと1つ以上のクライアントマシンでテストベンチをセットアップします。いくつかのツールを使用して、サーバーで使用可能なリソースの量を制限するか（例：）ulimit、サーバー上で干渉アプリケーションを実行します。サーバーがクライアント要求をどのように処理するかを測定します。上記の徐々に増加/減少する干渉負荷/利用可能なリソースを繰り返します。最後に、ドットを含むn次元の空間を取得します。一度に1つのパラメーターのみを変更し、他のパラメーターをすべて通常の値（またはいくつかの値）に修正する方が簡単な場合があります。この場合、1つの軸にサーバーパフォーマンス（たとえば、ユーザー/リクエストの数）を、他の軸にリソース使用率/可用性を備えた2Dグラフの束として結果を表すことができます。
アプリケーションがアプリケーションのいくつかの部分で複数のサーバーを使用し、その量と比率を変えることができるより複雑なシナリオがありますが、私はそうではないと思います。これが重要な場合、せいぜいスレッド/プロセスの数を変えることをお勧めします。
アプリケーション全体を測定する場合、通常、ソースコードにアクセスする必要はありません。ただし、コードの特定の部分（たとえば、DBまたはUIのみ）を測定することは興味深いかもしれません。その後、ソースコードを使用して、測定用にこのモジュールのみを公開し、テストを実行できます。これはマイクロベンチマークと呼ばれます。
例を探しているなら、アカデミックな記事にそれらの多くがあります。Googleの学者を検索して、パフォーマンスの評価と好みの条件を探します。
スケーラビリティは、実際のアプリケーションの定量化可能なプロパティではありません。
実際には、スケーラビリティとは、さまざまな次元で増加しているワークロードをサポートできることです。
アプリケーションを開始するには、既存のハードウェアリソースで増加するワークロードをサポートします。ただし、制限に達するポイントはさまざまです。たとえば、メモリの量、コアの数、データ構造の競合、データベースのスループットなど。これらの制限の1つに達するたびに、ワークロードの増加をサポートするために異なるアプローチをとる必要があります。スケーラビリティとは、乗り越えられない制限に達するまで、または大幅な再設計を行う必要がある前に、ワークロードをどれだけ長く維持できるかということです。