サーバーが大量のデータをクライアントにプッシュするアプリケーションを開発したいと考えています。(20 ミリ秒ごとに 20 kb) 500kbps。データはすべて double/float 値です。
データが http 経由でプッシュされる Web アプリと比較して、デスクトップ アプリ (Java Swing アプリ) に固有の何かがこのユース ケースのより良いオプションになるかどうかという質問に答えようとしています。
Javaスイングアプリと、そこでサーバーからクライアントへのデータ転送がどのように行われるかについて何かありますか。これにより、Webアプリ（アプリサーバーとしてのTomcat ..クライアント側のJS）と比較して高速になります。
Web サーバーとアプリケーションが同じローカル ネットワーク上にあるとしたら、答えはさまざまです。
私の投票はデスクトップですが、私は偏見があります（あなたが持っている唯一のツールがハンマーである場合...）
私の最初の考えは、スレッドとカスタムネットワーキングです。必要に応じてプッシュおよびプルプロトコルの追加の利点を得ることができます（ええ、これはWeb環境で取得できますが、Javaはこのために設計されており、AJAXはこのニーズに対応しています）
また、多様でカスタマイズ可能なUIツールキットをプッシュしますが、HTMLを使用してこれを実現できると主張する人もいるかもしれませんが、個人的には、Swingツールキットの実行と保守がより高速であることがわかりました。
欠点は、各クライアントマシンにアプリをインストールし、更新に対処する必要があることです。
それはとにかく私の一般的な意見です、それが役立つことを願っています
もう1つの質問は、アプリが何をする必要があるかということです。
UI が一度に 1000 メートルを表示することはほとんどありません。ユーザーは一度に少数のメートルしか見ない可能性が高いです。UI は、画面に表示されるメーターについてのみ更新する必要があります。これにより、負荷が大幅に軽減されるはずです。ネットワーキングとキャッシュ データベース コンポーネントが Web とデスクトップ アプリの両方でほぼ同じであると仮定すると、実際の差別化要因は、チャート/グラフのレンダリング速度と、それを使用する頻度または人数になります。
プロトタイピングに関する MadProgrammer の提案は理にかなっています。プロトタイプから得られたテスト データは、パフォーマンスの問題に答えます。
ウェブベースは、デスクトップ、タブレット、スマートフォンから使用できるため、より便利で価値があります。いつでもどこでも、できるだけ多くのユーザーの前にデータを取得することが望ましいと思います。また、人間の目は 20ms の更新を検出できないと思います。おそらくそれをもっと長くしても、ユーザーはそれに気付かないでしょう. 動画は 1 秒あたり約 25 フレーム、つまり 40 ミリ秒/フレームです。
予想される同時ユーザー数は? どちらもスケーラブルにすることができるため、ソリューションに影響を与えるべきではないと思います。