0

最終的にTomcatへのWARとしてデプロイされるWebアプリケーションを設計/開発しています。このアプリケーションの機能の1つは、ユーザーが画像をサーバーにアップロードして編集（サムネイルの生成など）できることです。内部では、ImageMagickとそのJavaアダプタライブラリを使用しますIM4Java。

初期のプロトタイプでは、アプリケーションを再デプロイするたびに、ImageMagickがサーバー上で「ウォームアップ」するのに時間がかかることが示されています。これにより、次の2つの可能性のいずれかを検討するようになりました。

  • ImageService.warプライマリアプリと一緒にデプロイし、基本的に内部へのすべての呼び出しを処理するWebサービスを作成しますIM4Java（たとえば、RESTfulサービスを公開し、リクエストを受信するとImageMagickを実行するだけです。プライマリWebアプリは、編集されたファイルを見つけることができません。同じローカルファイルシステム上）; また
  • Threadサブクラス（つまり）を作成し、ImageServiceThreadそれを開始してデプロイ時に実行し、Tomcatがアプリをアンデプロイするときにシャットダウンされることを確認します。

これらの2つの見通しにより、この問題についてより抽象的な意味で考えるようになりました。作業を別のスレッドに委任する必要があるのはいつか、本格的な別のアプリ（この場合はWAR）を作成するのが適切なのはいつですか。

私たちのプライマリアプリは、この「イメージサービス」の唯一のユーザーになります。これにより、別のWARはやり過ぎで不要だと思います。しかし、Tomcat内でのスレッド化を扱ったことはなく、スレッドのライフサイクルがプライマリ/メインアプリスレッドのライフサイクルと一致するようにスレッドを生成して強制終了できるかどうかはわかりません。

そのような決定の一部としてどのような要素を考慮する必要がありますか？前もって感謝します。

4

2 に答える 2

1

ImageMagickは「ウォームアップ」するのに少し時間がかかります

サーブレットコンテナの外部でメモリ/CPUを集中的に使用する操作をオフロードすることをお勧めします。実際、イメージサービスを別のJVMで起動します。

アプリケーションはメモリに画像をロードして編集するため、Webアプリケーションの他の部分のパフォーマンスに影響を与えることで、サーブレットコンテナのパフォーマンスを妨げるガベージコレクションが頻繁に発生することが予想されます。

于 2012-06-15T19:05:29.117 に答える
1

正しく実行する必要があるWebアプリケーションにImageMagickのプリロードを確実に保持します。そうすれば、2つのWebアプリを一緒にデプロイする必要があることを決して忘れません。

特定のWebアプリが必要とするすべてのものを1つの場所にまとめておくことをお勧めします。そのため、WAR形式が作成され、ServletContextListenersなどが存在します。

正直なところ、IMのプリロードをわざわざ「スレッド化」するかどうかはわかりません。aからサンプルコマンドを実行して、ServletContextListener同期的にロードするだけです。

于 2012-06-15T21:04:19.237 に答える