ブラウザから複数の AJAX リクエストが送信されています。私の UI は複数のビューで構成されており、AJAX リクエストはそれらのビューを同時に設定しようとしています。場合によっては、10 を超える同時要求をクライアントから送信し、サーバーで同時に処理する必要があります。
しかし、単一ドメインへの最大同時リクエストに対するブラウザの制限と、HTTP の「サーバーは、リクエストが受信されたのと同じ順序でリクエストへのレスポンスを送信する必要があります」という制約のため、リクエスト処理で私ほど多くの同時実行性を導き出していません。したいでしょう。
私のアプリケーションの観点からは、リクエストを送信した順序で応答する必要はありません。たとえば、view1 の前に view8 が入力されても問題ありません。
Servlet 3.0 コンストラクトを使用した非同期処理は、問題の片側 (サーバー側) のみに対処しているように見えるため、アプリケーションの同時実行性を最大化するために十分に活用することはできません。
私の質問は次のとおり です。いくつかの適切な構造を見逃していますか? (「別のサブドメインからイメージをホストする 」などの回避策とは対照的に「適切」)より多くの同時実行性を得ることができますか?
これは、多くの Web UI が必要とするもののようです。そうでない場合は、UI を間違った方法で設計しています。いずれにせよ、ご意見をお寄せいただければ幸いです。
Edit1:私の利点として、膨大な数の同時クライアントをサポートする必要はありません。アプリにアクセスする同時クライアントの最大数は 100 未満です。その事実を考えると、サーバー側で十分な処理能力を利用できる場合、基本的にこれらのクライアントのエクスペリエンスを強化しようとしています。
Edit2:私たちのアプリケーション/API は「パブリック」消費用ではありません。例: 私の会社の Web メール アプリのようなものです。インターネット上でホストされていますが、誰でも利用できるわけではありません。関連する少数の人々による消費のみを目的としています。その情報を提供している理由は、(REST) API ユーザーと通常の Web サイト ユーザーを区別しているように見える SO/Twitter と私のアプリを区別するためです。私たちの場合、そのように区別するべきではないと考えており、両方に単一セットの REST エンドポイントを提供したいと考えています。
仕様 (RFC2616) の制限の背後にある理由は、「これらのガイドラインは、HTTP 応答を改善し、輻輳を回避することを目的としています。」. しかし、イントラネット Web アプリにはより贅沢な機能があり、それほど制限する必要はないはずです!?