1

JBossコンテナで実行されているサーブレットによって生成された動的コンテンツと、Apache+mod_jkによって処理されている静的コンテンツ/負荷分散を使用するWebアプリケーションに取り組んでいます。

クライアント側はjQueryを使用してサーブレットにAJAXリクエストを作成し、サーブレットはそれらを処理して、大きなJSONレスポンスを生成します。

私が気づいたことの1つは、元の作成者が以下のようなものを使用してサーブレットの出力ストリームを手動で圧縮することを選択したことです。

 gzout = new GZIPOutputStream(response.getOutputStream());

これは、Apache側でmod_deflateを使用して処理できましたか？あなたがこれを行うことができるならば、それはより良い習慣と考えられますか、あなたはその理由またはなぜそうではないかを説明できますか？

4

2 に答える 2

1

あなたの場合、Apache内でHTTP圧縮を適用する方が理にかなっていると思います。

サーバーがこのタイプの応答を圧縮するように適切に構成されている場合（アプリケーション/ json、サーバー側のコードが正しいコンテンツタイプを設定している場合）、とにかく手動圧縮後に無駄に再圧縮されています。

また、gzipをサポートしていないクライアントがリクエストを行った場合はどうなりますか？サーバーレベルで応答を圧縮している場合は、要求のaccept-encodingヘッダーに基づいて自動的に適切に応答します。

于 2011-05-26T14:55:25.730 に答える
0

少し追加の調査では、いくつかの優れた代替案が示されています。

問題：

  1. ApacheとJbossの間に存在するネットワークチャネルがあります。jboss側でいかなる種類の圧縮も行わないと、Apacheとクライアント間で発生するのと同じ遅延と帯域幅の問題が発生します。

ソリューション：

  1. Apacheでmod_deflateを使用して、jbossからの非圧縮応答を受け入れ、クライアントに配信する前に圧縮することができます。これは、特定のネットワークトポロジ（Dave Wardによって提案された）である程度意味があることがわかりました。

  2. JavaEEフィルターを適用できます。これにより、JBossコンテナが存在する前に応答を圧縮してフィルタリングします。これには、ビジネスサーブレットに大量の厄介なGZIP関連コードがなくても、JBossレベルで圧縮できるという利点があります。

  3. JBoss withは、デフォルトでサーブレットエンジンとしてTomcatを使用します。$ JBOSS_HOME / deploy / jbossweb-tomcat55.sarに移動すると、server.xmlファイルを編集してHTTP/1.1コネクターの「compression=on」属性をオンにすることができます。これにより、コンテナから送信されるすべての応答が圧縮されます。

2と3の間のトレードオフは、さまざまなサーブレットのピースミールを圧縮するか、すべての応答を圧縮することです。

于 2011-05-26T15:56:22.363 に答える