1 はじめに
JSF ビジネス スレッド プールは、JDK のスレッド プール テクノロジを使用し、デフォルトでキャッシュ モードを採用します (コア スレッドの数は 20、スレッドの最大数は 200)。さらに、固定スレッドサイズモードも用意されており、どちらのモードでもリクエストキューのサイズを設定できます。
この記事の目的は、簡略化されたシナリオ (「単一サービス アプリケーション」) での負荷テストを通じて「JSF ビジネス スレッド プール サイズ構成」のベンチマーク結果を提供し、一般的に適用可能な結論を導き出すことです。
この記事の対象読者には、ストレス テスト エンジニア、開発、デプロイメント、運用およびメンテナンスのエンジニア、JSF スレッド サイズを合理的に構成する必要があるアーキテクトが含まれます。この記事では、JSF サーバーの他の構成項目については説明しません。また、「複合サービス アプリケーション」の適切な構成についても説明しません。この記事で提供される結論は、ストレス テスト ケースやビジネス スレッド プールのサイズを評価するための基本的な方法を設計するための参考として使用できるため、実際に JSF ビジネス スレッド プールのサイズを合理的に構成できます。JSF ビジネス スレッド プール サイズの適切な構成は、忠実度の高い負荷テストの結果に基づく必要があることに注意してください。
「単一サービス アプリケーション」とは、アプリケーションに提供されるインターフェイスが 1 つだけ含まれ、そのインターフェイスにメソッドが 1 つだけ含まれることを意味します。
「複合サービス アプリケーション」とは、複数の提供インターフェイスを含むアプリケーション、または複数のメソッドを含むインターフェイスを指します。
2. テストケースの説明
このベンチマーク テストでは USF3.0 権限システムを選択し、それを単一のサービス プロバイダーにカスタマイズしましたが、プロバイダーの 1 つのメソッドのみがテストされたため、「単一のサービス アプリケーション」とみなすことができます。テストでは、CPU がベンチマーク テストのコア リソースとして使用され、JVM ガベージ コレクターの影響を考慮して、単純なテスト データを使用してサービスへの各呼び出しの一貫性を確保し、YGC が規則性 (つまり、一定のコール量で一度に 30+ms の YGC が発生します)、FGC の影響はありません。
テスト ケースの設計では、テスト プロセス中にサービス可用性率が 100% に達するように、すべての依存サービス リソースは無制限です。当社の主要パフォーマンス指標は TP99、つまりサービス応答時間の 99% が 10 ミリ秒未満である必要があります。
さまざまなスレッド プール モードでパフォーマンスをテストするために、JSF スレッド プールのキャッシュ モードと固定モードを使用し、各モードで複数のテスト セットを実行して、システムの最大負荷条件を確認しました。
テストアプリケーション：USF3.0許可制（カスタマイズ処理）
テスト サービス: com.jd.susf.service.api.SusfPermissionService#findUserInfo、ユーザー情報に基づいて Redis からデータをクエリすることによって返されるサービス。
ハードウェア構成: シングル 4C 8G
テスト方法: Forcebot システムは、JSF ビジネス スレッド プールに対するシステム負荷テストをキャッシュ モードと固定モードで実行するためにラダー プレッシャー方式を採用しました。
SLA 要件の策定: サービス応答時間 <10ms の TP99
注: USF3.0 権限システムをカスタマイズし、サービス プロバイダーの構成データを調整し、com.jd.susf.service.api.SusfPermissionService のみを保持しました。
3.試験結果と分析
3.1. キャッシュされたスレッドプールのシステム負荷
図: さまざまな同時ユーザー数 (1 ～ 200) での JSF デフォルト スレッド プール (キャッシュ、スレッド = 200) のシステム負荷図
| 同時ユーザー数 | TP99 | スループットTPS | CPU使用率(%) |
|---|---|---|---|
| 1～23 | <8ms | 直線的な成長 | 直線的な成長 |
| 24 | 8ミリ秒 | 6553 | 99.62 |
| 25 | 11ミリ秒 | 6607 | 99.83 |
| 26～79 | 急成長 | 成長が遅い | 99+ |
| 80 | 74ミリ秒 | 6928 | 99.82 |
| 81~199 | ゆっくりと増加する | ゆっくりと衰退する | 99.82 |
| 200 | 99ミリ秒 | 6230 | 99.94 |
概要: デフォルトの JSF スレッド プール構成には大きなリスクが伴います。システムは最大 24 の同時実行をサポートできますが、24 を超える同時実行に達すると、SLA を満たすことができません。
3.2 固定スレッドプール(キュー)のシステム負荷
図: 異なる同時ユーザー数 (1 ～ 50) での JSF 固定スレッド プール (固定 + キュー) のシステム負荷図
| JSFビジネススレッドの数 | サポートできる同時ユーザーの最大数 | TP値(50/90/99/999) | スループット (TPS) | CPU最大使用率(%) |
|---|---|---|---|---|
| 4 | 11 | 7/8/10/18 | 1531年 | 27.67 |
| 8 | 25 | 8/8/10/18 | 3113 | 46.45 |
| 16 | 50 | 8/8/10/21 | 6228 | 87.97 |
| 20 | 23 | 3/4/10/15 | 6409 | 99.92 |
| 24 | 22 | 3/4/7/15 | 6178 | 99.86 |
| 25 | 22 | 3/4/6/15 | 6182 | 98.83 |
表: JSF 固定ビジネス スレッド プール (固定 + キュー) は、TP99<10ms のシステム最大負荷 (最大同時ユーザー数) を満たします。
まとめ：
① 固定スレッドモードではCPU使用率に上限があります。
② キューを使用すると、システムの同時実行性のサポートが効果的に増加し、スループットも向上します。ただし、タスクがキューで待機しているため、サービスの応答時間は「上げ潮がすべてを持ち上げる」ように見え、一定のリスクがあります。
3.3 固定スレッドプールのシステム負荷
図: JSF 固定スレッド プール (固定) モードでシステムの同時ユーザー数が最大の場合のシステム負荷
| JSFビジネススレッドの数 | 同時ユーザー数 | TP99 | スループット (TPS) | CPU最大使用率(%) |
|---|---|---|---|---|
| 4 | 4 | 5 | 1063 | 20.26 |
| 8 | 8 | 5 | 2216 | 36.62 |
| 16 | 16 | 6 | 4262 | 68.56 |
| 20 | 20 | 5 | 5550 | 86.22 |
| 24 | 24 | 8 | 6711 | 99.62 |
| 25 | 25 | 16 | 6644 | 98.77 |
| 26 | 26 | 19 | 6744 | 99.93 |
概要: 固定スレッド プール (固定) のパフォーマンスに基づいて、CPU リソースの完全な使用率のバランスをとり、SLA の要件を満たすために、適切な数のスレッドを設定する必要があります。スレッドの数が少なすぎると、 CPU リソースの無駄遣いにつながり、スレッド数が多すぎると実行できなくなります。
4 結論
テスト結果とデータ分析に基づいて、次の結論を導き出します。
- JSF スレッド プールのデフォルト構成は、同時実行性が高いシナリオでは危険です。オンラインの実稼働環境に JSF サービスが配置されているサーバーは、200 スレッドでも SLA を満たすことができます。最大 200 スレッドのスレッド プール構成では、同時実行性が高いシナリオではサーバーが過負荷になる危険があります。スレッド プール サイズの適切な構成は、忠実度の高い負荷テストから行う必要があります。
- 十分な数のスレッドによりリソース (CPU) 使用率を確保できる: ビジネス タイプのサービスには通常、特定の IO 操作 (ネットワーク、ディスクなど) があり、スレッドの実行中に待機が発生します。CPU 使用率は高くなく、同時実行性が必要です。スレッドの数を増やし、より多くのスレッドが CPU 割り当てに参加できるようにすることによってのみ、CPU 使用率を改善できます。サービス内の IO 操作が増えると、待機時間が長くなり、より多くの同時スレッドが必要になります。IO 操作を伴うビジネス サービスの場合、負荷テストのスレッド数は 2N (N はサーバーの CPU コアの数) から開始できます。
- スレッド数が多すぎると、システムの SLA が低下するだけです。スレッド数がすでに CPU の 100% を利用できる場合、スレッド数を増やすと、スレッドは十分な CPU 割り当てを取得できなくなるため、応答が遅くなります。サービスの時間が増えます。一定の範囲内では、TP99 は SLA 要件を満たしている可能性があり、システムのスループットもわずかに向上します。スレッド数を増やし続けると、TP99 はシステム要件を満たすことができなくなり、システムのスループットが低下し始めます。
- 固定数のスレッドにより、システムが耐える必要がある負荷容量を保護できます。固定数のスレッドにより、システムの CPU 使用率が特定の負荷範囲に制限され、システムの安定した動作が保護され、応答時間が保証されます。 TP99 ですが、システムの同時実行機能も制限されます。キュー サイズを適切に設定すると、システムの同時実行性が向上し、システム TP99 には影響しませんが、サービス全体の応答時間が増加し、不安定な変更が発生するため、危険です。
- CPU を 100% 高負荷で実行する: 通常、サービスの外部 SLA コミットメントは、インフラストラクチャと依存サービスの不安定性を考慮するため、サービスの実際のパフォーマンスよりも高くなります。したがって、CPU が 100% に達した場合でも、外部応答時間の TP99 コミットメントに影響を与えることなく、スレッド数を一定量増やすことができます。これにより、システムの同時実行機能が向上します。システムは高負荷下でも動作できますが、システムの信頼性を向上させるためにさらに安定性テストを行う必要があります。
要約すると、スレッド プール サイズの適切な構成は、ビジネス要件とシステム リソースの条件に基づいて評価およびテストする必要があり、システムの安定した動作を確保してユーザー SLA を満たすために、適切なバッファ スペースを予約する必要があります。
5. 付録
付録 1: 統計指標と用語の説明
同時ユーザー数: 同時にリクエストを開始するユーザーの数。
TP 値 (50/90/99/999) : クライアントの TP 値、単位はミリ秒、データは Forcebot から取得されます。
スループット TPS : データは Forcebot から取得されます。
CPU 使用率 (%) : データは PFinder から取得されます。
JSF ビジネス スレッドの数: JSF ビジネス スレッド プール内のスレッドの数 (例: <jsf:server id="jsf" protocol="jsf" threadpool="fixed" thread ="16" / > )
fix/cached : JSF ビジネス スレッド プールのスレッド プール タイプ (例: <jsf:server id="jsf" protocol="jsf" threadpool="fixed" thread="200"/>)
最後に:以下の完全なソフトウェア テスト ビデオ チュートリアルが編集され、アップロードされています。必要な友人は自分で入手できます[100% 無料保証]
ソフトウェアテスト面接文書
私たちは高給の仕事を見つけるために勉強しなければなりません。以下の面接の質問は、アリババ、テンセント、バイトなどの一流インターネット企業の最新の面接資料からのものであり、バイトの上司の中には権威ある回答をしている人もいます。 set 面接情報に基づいて、誰もが満足のいく仕事を見つけることができると思います。
