0

私はクライアント側のプログラミングのバックグラウンドを持っています (主に C++)。ただし、Java でいくつかの小さなサーバー側プロジェクトに参加する必要が時々あるため、経験豊富なサーバー側の人々からのアドバイスが必要です。アプリケーションサーバーについてはよくわかりません。

プログラムがアプリケーション サーバー (GlassFish や JBoss など) をいつ必要とするかを決定するための経験則や考慮事項はありますか?

Java で記述された 2 つのサーバーがあり、両方とも専用マシンで実行されています。1 つのサーバーは、App Server なしで Tomcat で実行されます。2 番目のサーバーは、アプリケーション サーバー (Glassfish) で実行されます。

中間に位置するかなり単純なプログラムを作成する必要があります。これがプログラムが行うことです

  • ソケットでリッスンします。接続が最初のサーバーから来ると、スレッドを作成して接続を受け入れ、リッスンを続けます。

  • スレッドは最初のサーバーから少量のデータ (たとえば 100 ～ 200 バイト) を取得し、データのごくわずかなフォーマットを行い、Web サービス呼び出しを介して 2 番目のサーバーに渡します。Web サービス呼び出しの戻り値を取得し、それに基づいて何らかの処理を行います - 約 10 ～ 20 行のコードである可能性があります - これは主要な処理ではありません - 別の (3 番目の) サーバーでのいくつかの Web サービス呼び出しです。この後、最初のサーバーにいくつかのデータが返されます。これもそれほど多くはありませんが、50 バイトの可能性があります。

  • 私のプログラムは Web サービスではありません。最初のサーバーから特定の形式でメッセージを取得し、最初のサーバーから受信したデータに基づいて 2 番目のサーバーに Web サービス呼び出しを行うだけです。ある意味では、このように考えることができます。最初のサーバーが 2 番目のサーバーに Web サービス呼び出しを行うためのプロキシとして機能します。

すべての主要な作業は、Tomcat サーバーで実行されるアプリと GlassFish で実行される Web サービスによって実行される最初のサーバーによって行われます。これらは両方とも十分にテストされたプログラムです。私が書きたい中間プログラムはとてもシンプルで、半日で完成します。ただ、気になるのは負荷に耐えられるかどうか。

このJavaプログラムを通常のWindowsサービスとして実行できるかどうか、またはGlassfishや他のアプリケーションサーバーのようなものが必要かどうかを判断するために、どのような規則/考慮事項がありますか.

1 分/1 時間あたりの接続数を考慮する必要がありますか? 接続ごとにスレッドをフォークしますが、スレッド自体はそれほど長くは存続しません。接続数のどのしきい値で、アプリケーション サーバーと見なす必要がありますか? 他の考慮事項はありますか？可能であれば、アプリケーション サーバーは避けたいと思います。

App Server で実行するかどうかは 1 つの質問にすぎません。ここで見逃している質問は他にありますか?

4

3 に答える 3

4

アプリケーション サーバーは、パフォーマンスを向上させないという点で、魔法のようなものではありません。実際、あなたが概説したような単純なアプリケーションの場合、ほとんどのアプリケーション サーバーが導入するすべての余分なオーバーヘッドのために、アプリケーション サーバーは逆の効果をもたらす可能性があります。

アプリケーション サーバーは、インフラストラクチャ コンポーネント、エンタープライズ レベルの開発のための実用的なパターン、および標準仕様の実装を提供します。これらは主に、大規模な開発作業を組織化し、比較的短期間の接続をより多くの大規模に設定するのに役立ちます。とはいえ、Tomcat や Jetty などの軽量サーバーは、それらが提供するインフラストラクチャに既に精通している場合に使用できます。特に、インバウンド HTTP 接続処理を提供します。

ただし、問題の説明に基づいて、Apache HttpComponentsなどのライブラリを使用してスタンドアロンの Java サービスを作成し、HTTP および WebService クライアント機能を処理する方がよいと思います。インバウンド接続を処理するためにどれだけの追加作業が必要かは明確ではありません。単純なソケットの場合、これを自分でプログラムするのは非常に簡単です。

同時にサポートする必要がある接続の数に関する説明はあいまいです (そして、それはすべて相対的です)。接続ごとに 1 つのスレッドが必要で、数百の接続をサポートすることが予想される場合は、スレッド接続プールを使用して接続処理を実装し、サーバーの機能を使い果たす前に新しい接続が確実にブロックされるようにすることをお勧めします。そのルートに進む場合は、Java 5+ ExecutorServiceと関連クラスを確認してください。

あなたのニーズが単純な場合、アプリケーションサーバーが多くの利益をもたらすとは思えません。

于 2012-12-10T17:51:11.003 に答える
1

パフォーマンスの問題は、アプリケーション サーバーの選択よりも、ネットワーク トポロジとマシン ハードウェアの影響を大きく受けると思います。JBoss などの一部のアプリケーション サーバーは、クラスターを作成および管理するための管理ツールを提供しますが、すべてのアプリケーション サーバーは、適切なツールを使用して同様にセットアップできます。そうは言っても、 jettyやgrizzlyのような埋め込み可能なサーブレット コンテナーを使用すると十分に役立つと思います。これにより、必要になる可能性が低い EE 準拠の余分な荷物なしで、アプリケーション サーバーによって伝えられる構成と移植性の利点が得られ、開発構成のセットアップが容易になります。

于 2012-12-10T18:14:28.080 に答える
1

ツールを評価する際の基本的なルールは、ここでも適用する必要があります。作業が容易になるかどうかです。

問題は、アプリケーション サーバーによって提供される機能が私のユース ケースに十分に対応しているかどうかであり、制限が私を制限することはないということです。

ユーザーケースの説明に基づいて：

JavaEEアプリケーションサーバーは、サーブレットの抽象化を提供してHTTPリクエストを簡単に管理します（理論的には、アプリサーバーの実装に新しいものを追加することで、自分で行う必要がある他のタイプのリクエストを実装できます）。Jax-WSまた、Web サービス エンドポイント作成の経由またはJax-RS抽象化も提供します。

これらの抽象化のコストは、アプリケーション サーバーがスレッドを管理することです。実装のほとんどは接続にスレッド プールを使用するHTTPため、リクエストごとにスレッドを作成するコストはかかりません。

さらに、fullJavaEEは簡単​​な宣言型トランザクションとセキュリティ ( EJB)、永続的なメッセージングなどを提供しますJMS。

提供された抽象化の付加価値とそれらのコストのバランスを取るのはあなた次第です (Java 標準はほとんどのユースケースに適合し、平均的なプログラマーよりも優れたパフォーマンスを発揮するように作成されているため、ほとんどの場合、制御が少ないほどより良い動作が得られます)コード...）。

そのため、必要な機能を確認し、最も簡単な方法 (クイック) を使用して機能を満たし、POC を作成して負荷テストを行う必要があります。

ちなみに、Tomcatはアプリケーション サーバーであり、すべての JavaEE 部分を実装しているだけではなく、basique Web 関連の機能 (サーブレット、ただしデフォルトでは WS または restfull ws はありませんが、これは libs によって簡単に追加できます) のみを実装しています。新しい Jboss と Glassfich は、Tomcat と同様のサイズとパフォーマンスで、はるかに多くの機能 (展開時のロードが簡単) を提供します。

于 2012-12-10T18:00:57.150 に答える