Tomcat の同時実行能力を SpringBoot に組み込む方法

同時コンテナの問題を発見する

各スレッドがリクエストを行い、単一のインターフェイスで 6000 スレッドのストレス テストを実施します。 5 回。スレッドは 5 秒以内に作成されました。途中で、リクエストの応答時間が長すぎて、エラー率が 43% に達しました。この同時処理能力は、より優れた構成のサーバーでは比較的弱くなります。

SpringBoot の基礎となる層を深く掘り下げて理由を理解してください

メタデータの構成については、SpringBoot の公式ドキュメントで説明されています

最も一般的に使用される設定項目のポートのデフォルト構成がその中にあります。

デフォルトの組み込み Tomcat 構成

1.server.tomcat.accept-count: 待機キューの長さ 割り当て可能なスレッドの数が使い果たされると、後続のリクエストは待機キューに入って待機します。 、キューがいっぱいになるのを待った後に処理を拒否します。デフォルトは 100 です。

2.server.tomcat.max-connections:接続の最大数、デフォルトは 10000

3.server.tomcat.max-threads:作業スレッドの最大数、デフォルトは 200,

4.server.tomcat.min-spare-threads: 作業スレッドの最小数、初期割り当てスレッドの数、デフォルトは 10

デフォルト設定では、接続数が 10,000 を超えると接続は拒否されます

デフォルト設定では、トリガーされたリクエストが 200 を超え、100 リクエスト (キューの長さを待機しているワーカー スレッドの最大数) を超えると拒否されます

これらのメタデータ Spring はもちろん外部設定機能を提供します

#更改内嵌tomcat参数
server.port=8080
## 等待队列长度，默认100。
server.tomcat.accept-count=1000
## 最大工作线程数，默认200。（4核8g内存，线程数经验值800，操作系统做线程之间的切换调度是有系统开销的，所以不是越多越好。）
server.tomcat.max-threads=800
## 最小工作空闲线程数，默认10。（适当增大一些，以便应对突然增长的访问量）
server.tomcat.min-spare-threads=100

SpringBoot には Tomcat が組み込まれており、デフォルト設定では Tomcat の最大スレッド数は 200 であり、最大スレッド数は 200 です。接続数は10,000です。サポートされる同時実行性の量は接続数を指します。200 個のスレッドが 10,000 個の接続をどのように処理できるのでしょうか?

現在 Tomcat には 3 つの接続処理モードがあります。1 つは BIO (1 つのスレッドが 1 つの接続のみを処理する)、もう 1 つは NIO (1 つのスレッドが複数の接続を処理する) です。 HTTP リクエストには時間がかかりすぎず、通常、複数の接続が同時にメッセージを受信することはないため、1 つのスレッドで複数の接続を処理しても大きな問題はありません。

Tomcat のこれら 3 つのモードについては後で詳しく紹介するので、ここでは詳しく説明しません。

Tomcat が起動すると、ログを通じてコネクタがどの動作モードを使用しているかを確認できます:

Starting ProtocolHandler ["http-bio-8080"]
Starting ProtocolHandler ["http-nio-8080"]
Starting ProtocolHandler ["http-apr-8080"]

デフォルト値は spring-boot-autoconfigure-versionnumber.jar にあります (たとえば、 : spring-boot-autoconfigure-2.1.0.RELEASE) パッケージを解凍し、/web/ServerProperties.class ファイルを逆コンパイルして、デフォルトの構成を確認します。

カスタマイズされた組み込み Tomcat 開発

KeepAlive について

Jmeter を使用した Http リクエストデフォルトは次のとおりです。 keepAlive を有効にする

Http の KeepAlive リクエストは、クライアントが Http リクエストをサーバーに送信するときに行われ、KeepAlive リクエスト ヘッダーが含まれている場合、HTTP クライアントがサーバー間で KeepAlive 接続が確立されることを意味します。この接続の目的は、対応する応答をサーバーに送信した後、サーバーがすぐに切断せず、接続の再利用を試みることです。

このソリューションは、ステートレスであり、毎回接続を切断して新しい接続を作成する必要がある HTTP の応答によって引き起こされる時間のかかる問題を解決するために使用されます。

しかし、Web ページのリクエストが開かれるたびにサーバーとの接続を長時間維持すると、サーバー上の接続数がすぐに使い果たされてしまうため、初期の Http1.0 にはそのようなことはありませんでした。 KeepAlive リクエストは設計されましたが、現在の Http1.1 と KeepAlive リクエストは、ますます多くのモバイル デバイス、さらにはユーザーの閲覧プロセス中にサーバーへの頻繁なリクエストを必要とする非常に複雑な Web ページの操作をサポートするように設計されています。したがって、KeepAlive 接続の確立はストレス テストを目的としたものではありませんが、実際にはアプリケーション シナリオでパフォーマンス上の利点がいくつかあります。クライアントであってもサーバーであっても、ネットワーク通信のやり取りを行うときに、毎回新しい接続を作成し、接続を切断し、Tcp/Ip 接続の確立に時間を無駄にしますが、必要なのはデータの送信のみです。

しかし、そのような設計にはいくつかの問題も発生します。サーバーが KeepAlive 1 の動作に制限を課していない場合、接続は何の操作も実行せず、応答もしないため、この接続は2. 一部の攻撃者は、KeepAlive 接続を悪意を持って使用して、サーバーに DDOS 攻撃を送信します。サーバー上の対応する接続​​は、攻撃者が攻撃するためのバックドアになるだけです。したがって、セキュリティのために、Tomcat の開発をカスタマイズする必要があります

Configuration

1. KeepAliveTimeOut: クライアントが応答しないミリ秒数が経過すると、KeepAlive は切断されます

2. maxKeepAliveRequests: リクエスト数が経過すると、KeepAlive は切断されます。切断され無効になります

在SpringBoot官方文档中提到了对内嵌容器的配置

//当spring容器内没有TomcatEmbeddedServletContainerFactory这个bean时，会把bean加载进spring容器
@Configuration
public class WebServerConfiguration implements WebServerFactoryCustomizer<configurablewebserverfactory> {
@Override
public void customize(ConfigurableWebServerFactory factory) {
　　//使用对应工厂类提供给我们的接口定制化我们的tomcat connector
　　((TomcatServletWebServerFactory)factory).addConnectorCustomizers(new TomcatConnectorCustomizer() {
　　　　@Override
　　　　public void customize(Connector connector) {
　　　　　　Http11NioProtocol protocol= (Http11NioProtocol) connector.getProtocolHandler();
　　　　　　//定制KeepAliveTimeout，设置30秒内没有请求则服务器自动断开keepalive连接
　　　　　　protocol.setKeepAliveTimeout(30000);
　　　　　　//当客户端发送超过10000个请求则自动断开keepalive连接
　　　　　　protocol.setMaxKeepAliveRequests(10000);
　　　　}
　　});
}
}</configurablewebserverfactory>

以上がTomcat の同時実行能力を SpringBoot に組み込む方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。