Java と Spring MVC を使用して Web サイトを開発しています。詳細を入力して画像を添付できるフォームがあります。ユーザーがフォームを送信すると (送信ボタンをクリック)、データと画像の両方がサーバーにアップロードされます。アップロードされた画像は、3 つの異なる場所で 3 つの異なるサイズでユーザーに表示されます。
私が現在行っているのは、画像を 3 つの異なる解像度にリサイズして保存することです。ただし、サイズ変更によって処理時間が長くなるため、アップロードが遅くなります。
処理を高速化する 1 つの方法は、2 つの並列スレッドを実行して変換と保存を行うことです。
他のより良いアプローチはありますか？
これを行うには、次の 3 つの方法が考えられます。
同期、シングルスレッド。
これが現在のソリューションです。画像のサイズ変更は、アップロード リクエストを処理する同じスレッドで順次 (1 つずつ) 実行されるため、合計リクエスト処理時間が長くなります (お気づきのように、プロセス全体が著しく遅くなります)。間違いなく、実装が最も簡単です。コントロールは、すべての画像が処理された後にのみユーザーに返されます (これは「同期」部分です)。
同期、並列化。
画像のサイズ変更は並列化することでメリットが得られる可能性が高いため、 を使用しCompletionServiceてすべてのサイズ変更タスクを送信し、それらを同時に処理するように設定し、すべてのタスクが完了するまで (つまり ) 待ってから応答を返すことができます。ユーザーは、すべての画像の準備が整うまで待つ必要があります。
非同期。
アップロード処理コントローラーは、サイズ変更タスクをサービスのキューに入れ、すぐに返します。サイズ変更サービスは、可能な限り迅速に画像を処理するために最善を尽くします。このアプローチの問題点は、コントロールがユーザーに返される短いウィンドウが作成されるが、サムネイルがまだ準備されていないことです。これを処理する一般的な方法 (YouTube など) は、実際の結果が準備できるまで、「まだ処理中です」というプレースホルダーのようなものを表示することです。
要件とページの動的性に応じて、最適なソリューションを選択できるのはあなただけです。たとえば、サーバーをポーリングして、サイズ変更ジョブが完了したかどうかを確認できます (プレースホルダーを実際の値に置き換えることができます)。画像のリサイズ)