1

/META-INF/resources/ の下に画像を含む jar をいくつか取得しました

すべての Tomcat サーバーのバランスを取るために、1 つの Apache をインストールしました。

今、これらのリソースを Web に提供する servlet3.0 アプリケーションを取得しました。

Tomcat が画像を提供するのは好きではありません。Apache が画像を提供するのが好きです (パフォーマンスのため)。

tomcat に .war ファイルを強制的に展開させずに、tomcat/work 内のフォルダーに展開できますか?

例

下に画像がありました

/opt/tomcat/webapps/MyApp.war!/WEB-INF/lib/LikeButton.jar!/META-INF/resources/like.png

わかりました、Tomcatはlike.pngを提供します

http:// localhost:8080/MyApp/like.png

しかし、彼はlike.pngを実際のディレクトリに抽出しません!

4

3 に答える 3

2

パフォーマンス上の理由だけで Tomcat よりも Apache (またはその他の httpd サーバー) を使用しても、パフォーマンスが大幅に向上するわけではありません。ただし、管理オーバーヘッドが追加されます。

とにかく、これらのファイルを自分で抽出できると主張する場合:

1) LikeButton.jar の実際のパスを見つけます。

String relativeWebPath = "/WEB-INF/lib/LikeButton.jar";
String absoluteDiskPath = getServletContext().getRealPath(relativeWebPath);
File likeButtonJar = new File(absoluteDiskPath);

2) ファイルを解凍します。このチュートリアルを使用して、ZipEntry本当に必要なものだけを抽出するためにいくつかの条件を追加するだけです。

于 2012-12-27T15:16:42.557 に答える
2

本当の問題は、そもそもなぜ Apache httpd を使用しているのかということです。

Tomcat が画像を提供するのは好きではありません。Apache が画像を提供するのが好きです (パフォーマンスのため)。

Apache httpd が何らかの有用な機能を提供している場合、それはこの質問に関連しており、それを述べる必要があります。それ以外の場合は、httpd を完全にダンプし、適切に構成された Tomcat を使用します (たとえば、APR または NIO コネクタを使用します)。

tomcat に .war ファイルを強制的に展開させずに、tomcat/work 内のフォルダーに展開できますか?

$ unzip MyApp.war -j WEB-INF/lib/LikeButton.jar \
  && \
  unzip -d /var/www/htdocs/ LikeButton.jar '/META-INF/resources/*'

WAR 内に多数の JAR ファイルがある場合は、それらのファイルごとに上記の手順を繰り返す必要があります。

さらに良いのは、ビルド プロセスの一部にして、静的コンテンツ ディレクトリまたは ZIP ファイルをビルドし、それらのファイルを Web サーバーに公開することです。それらをWAR事後から抽出することは、間違ったアプローチのようです。

于 2012-12-27T21:28:50.060 に答える
1

私が見るいくつかのオプションがあります：

  1. サーブレットアプリを変更して、画像がどこから参照されるかを構成できるようにします（パフォーマンスについて話すと、これにより任意の CDN（コンテンツ配信ネットワーク）も使用できるようになります-完全に異なるホストから画像を配信すると、さらに優れたものになります）パフォーマンスのため）。これに加えて、httpd で利用可能な場所に画像を抽出し、それぞれの URL を参照するようにアプリを構成する必要があります。

  2. Apache でキャッシュを使用して、Tomcat からイメージを要求し、次にキャッシュからイメージを要求します。これにより、更新されたバージョンを異なるイメージ/リソースでデプロイするときにキャッシュをフラッシュできます。キャッシュが適切に設定されると、サーブレット アプリを更新するだけで静的要素に触れる必要がないため、一般的に最も簡単なデプロイが提供されます。 - ファイルを別々に保管します。マイナス面は、アプリが正しいキャッシュ関連の http ヘッダーを提供する必要があることですが、これは肯定的な側面としてもカウントされる可能性があります。とにかくそうするべきです。

パフォーマンス要件に関する免責事項/コメント: 95% のケースで、測定の前にパフォーマンスの議論を行う必要があります。ほとんどの場合、アプリケーションのパフォーマンスは良好です。そうでない場合、Apache を介して画像を提供することは、パフォーマンスを改善するための最も効果的な方法ではないでしょう。これらの変更により、アプリサーバーのパフォーマンスを 2% 向上させることができますが、構成/展開の複雑さが改善されるため、システム管理と開発のパフォーマンスは 10% 低下します。

あなたが残りの 5% に属しており、その免責事項があなたの状況に当てはまらない場合は申し訳ありませんが、他の多くの人がこの質問を読んでおり、言及することは非常に重要な側面だと思います.

于 2013-01-02T08:34:17.470 に答える