SpringBootプロジェクトでのUndertowの使用、Undertow、Jetty、Tomcatの違いの比較

マイクロサービスアプリケーションを導入する際には、より軽量で高性能なWebサーバを使用する必要があります.これにより、サービスのパフォーマンスが向上し、コストが削減されるためです.
Undertow Undertowとはjavaで記述された柔軟な高性能Webサーバであり、NIOベースのブロックおよび非ブロックAPIを提供します.Lightweight(軽量級)Undertowは非常に軽量級で、Undertowコアjarパッケージは1 Mb以下である.実行時も軽量級であり、4 Mb未満のスタックスペースHTTP Upgrade Supportを使用する簡単な組み込みサーバがある(httpのアップグレードをサポート)HTTPのアップグレードをサポートし、複数のプロトコルがHTTPポートを通じて多重Web Socket Supportを行うことを許可する(WebScoket対応)UndertowはWeb Socketの全面的なサポートを提供し、JSR-356はサーブレット3.1 Undertowをサポートし、組み込みservletのサポートを含むサーブレット3.1のサポートを提供する.また、同じ配置でサーブレットとネイティブUndertow非ブロック処理プログラムEmbeddableを混在させることもできる(埋め込み可能)Undertowはアプリケーションに埋め込むか独立して実行できます.コードFlexible(柔軟性)Undertowフレームワークjarパッケージ:undertow-core.jar undertow-servlet.jar
Jetty
JettyはTomcatアーキテクチャよりも簡単です.JettyのすべてのコンポーネントはHandlerに基づいて実現され、その主な機能拡張はHandlerで実現することができる.Tomcatの全体的な設計は複雑で、tomcatはコンテナベースのアーキテクチャであり、開発者がtomcat機能を拡張するにはtomcatアーキテクチャを理解し、tomcatの規範に従う必要がある.Jettyはさらに軽量レベルであり、TomcatはJavaサーブレット仕様に従うほか、企業レベルのアプリケーションのニーズを満たすために多くのJEE特性を拡張しているため、Tomcatは重量レベルであり、Jettyよりも複雑な構成である.しかし、多くの一般的なインターネットアプリケーションでは、Tomcatの他の高度な特性を使用する必要はありません.そのため、この場合、Tomcatを使用するのはリソースを浪費します.このような劣勢は分布式環境下に置かれ,さらに明らかである.Jettyに変更すると、アプリケーションサーバごとに数メガメモリが節約され、大きな分散環境では多くのリソースが節約されます.また、Jettyの軽量レベルは、高い同時細粒度要求を処理するシーンでより迅速かつ効率的に見えます.Jettyはサードパーティのフレームワークを拡張しやすいので、カスタマイズしやすく、Jettyはより柔軟で、その挿抜性と拡張性に現れ、開発者がJetty自身を二次開発しやすく、自分のニーズに合ったWebサーバをカスタマイズします.それに比べて、ヘビー級のTomcatはもともと多くの特性をサポートしており、ダイエットするコストはJettyを豊富にするコストよりはるかに大きい.自分の理解では、肥満はダイエットしやすいということです.Jettyの軽量化によりメモリを節約
Jettyのデフォルトでは、NIO(非ブロックIO)による終了はI/Oリクエストの処理においてより優位であり、静的リソースの処理においてパフォーマンスが高い.tomcatはより安定で成熟しており、企業レベルでの占有率が大きい
Jettyは、パブリッククラウドの分散環境のニーズを満たし、Tomcatはエンタープライズ環境に適しています.大規模なエンタープライズアプリケーションをサポートする場合、Jettyは拡張する必要があるかもしれませんが、このシーンではTomcatがより優れています.
アーキテクチャから見ると、Tomcatは非常に忙しい接続を処理する上でより優れています.つまり、接続のライフサイクルが短いと、Tomcatの全体的なパフォーマンスが向上します.
Jettyは正反対で、Jettyは大量の接続を同時に処理することができ、これらの接続を長時間維持することができます.例えば、いくつかのwebチャットアプリケーションはJettyでサーバーを作るのに非常に適しています.宝を洗うweb旺旺旺はJettyをサーブレットエンジンとして使っています.
またJettyのアーキテクチャは非常に簡単なため、サーバとしてコンポーネントをオンデマンドでロードすることができ、不要なコンポーネントを取り除くことができ、サーバ自体のメモリオーバーヘッドを無形に減らすことができ、1回のリクエストを処理することも発生した一時的なオブジェクトを減らすことができ、パフォーマンスも向上します.またJettyのデフォルトではNIO技術がI/Oリクエストの処理に優れており、TomcatのデフォルトではBIOが使用されており、静的リソースを処理する際、Tomcatの性能はJettyに及ばない.
SpringbootでのUndertowの使用
デフォルトのTomcatコンテナを除去するなど、他のサービスコンテナを除去
依存導入org.springframework.boot     spring-boot-starter-undertow
Undertowパラメータの設定

server.undertow.accesslog.dir=     # Undertow access log directory.
server.undertow.accesslog.enabled=false     # Enable access log.
server.undertow.accesslog.pattern=common     # Format pattern for access logs.
server.undertow.accesslog.prefix=access_log.     # Log file name prefix.
server.undertow.accesslog.rotate=true     # Enable access log rotation.
server.undertow.accesslog.suffix=log     # Log file name suffix.
server.undertow.buffer-size=     # Size of each buffer in bytes.
server.undertow.buffers-per-region=     # Number of buffer per region.
server.undertow.direct-buffers=     # Allocate buffers outside the Java heap.
server.undertow.io-threads=     # Number of I/O threads to create for the worker.
server.undertow.max-http-post-size=0     # Maximum size in bytes of the HTTP post content.
server.undertow.worker-threads=     # Number of worker threads.

SpringBootでjettyを使う
他の容器、例えばTomcatの依存を取り除く
jetty依存の導入

    org.springframework.boot
    spring-boot-starter-jetty

Jettyパラメータの設定

server.jetty.acceptors=2 # acceptor   
server.jetty.max-http-post-size=0 # put post       
server.jetty.selectors=4 # selector   
spring.http.encoding.charset=UTF-8
spring.http.encoding.enabled=true
spring.http.encoding.force=true