5

クエリにすばやく応答できるサーバー アプリケーションを実装しようとしています。サーバーはJavaで実装されています。複雑な通信プロトコルに多くの時間を浪費したくないので、1) サーバーにクエリを実行する 2) サーバーにそのクエリに回答させる、ベストプラクティスの方法を探します。クエリと回答の両方が整数から整数リストにマップします。

関連：クエリ/応答プロトコルを処理し、着信クエリを管理する（それらをキューに入れる）複合フレームワークはありますか？

プレーン デーモンとして実装するか、Web サービスとして実装するかはわかりません。Web サービスは、別のマシンに比較的簡単に移動できるため、より柔軟に見えますが、プレーンなデーモンの方が高速に聞こえます。

4

6 に答える 6

3

デーモンは、柔軟性を犠牲にして短期的に高速になります。デーモンの利点は、バイナリ整数値のストリームとして、コンパクトな形式で返信を返すことができることです。これはあなたが得ることができるのと同じくらい速くなります。

リクエスト数が一定の制限を超えて増加した場合、ラウンド ロビンで DNS を使用して複数のマシンに負荷を分散できるため、HTTP サーバーを使用する利点はありません。

主な欠点は、このインターフェイスを簡単にデバッグできないことです (ほとんどのインターネット プロトコルでは、サーバーがリッスンするポートに telnet で接続し、いくつかのコマンドを実行して結果を確認できます)。また、何らかの理由でインターフェイスを変更する必要がある場合は、すべてのクライアントも変更する必要があります。このサービスを別の場所 (マッシュアップなど) で使用する必要がある場合、これはさらに悪化します。

したがって、より柔軟にしたい場合は、データ形式として HTTP や JSON などのプロトコルを使用してください。これはバイナリほどコンパクトではないため、応答時間は遅くなります。どの程度悪化するかは、データのサイズによって異なります。JSON でエンコードされた応答を標準の IP パッケージ (約 1500 バイト) に収めることができれば、おそらく違いに気付かないでしょう。

于 2009-02-12T08:46:53.487 に答える
2

これは一種の一般的な答えであることは知っていますが、デーモンと Web サービスのミリ秒の違いについて話しているのです。

そうは言っても、より柔軟なアーキテクチャを使用してください。優れた設計は、それを実行するために使用するテクノロジーよりもはるかに重要です。

数ミリ秒が本当に重要な場合、問題はどのテクノロジを使用するかではなく、キャッシングとロード バランシングを使用してそれをスケーリングする方法です。

于 2009-02-12T04:58:41.193 に答える
1

デーモン サーバーを開発する場合、クライアントに接続するために提供するインターフェイスは何ですか? ソケットや RMI などを実装することになります。スケーラビリティに関しては、非常に柔軟で保守が容易なソリューションではありません。

Web サービスを使用します。

于 2009-02-12T05:42:37.890 に答える
0

複数の方法を試していない限り、どれが「より良い」かはわかりません。最善の方法は、それぞれのプロトタイプを作成して試してみることです! やりたいことをすべて実行する必要はなく、基本的な部分 (事前定義されたデータを返すなど) を実行するだけで、負荷テストを行ってどちらが優れているかを確認できます。

最近では、最新のマシンは http が適切に機能するのに十分な速度で動作し、より標準化されているという追加の利点により、専用のクライアントを必要とせずに他のサービスがサーバーを利用できるようになると思います。

于 2009-02-12T09:48:59.843 に答える
0

パフォーマンスがそれほど問題である場合は、ある種のクラスター ソリューションのグリッドを使用する必要があると思います。Java グリッド/クラスター ライブラリの概要を以前に書きましたが、これは有用な背景です。

商用ソフトウェアがオプションである場合は、GigaSpaces (または、そうでない場合はフリーウェアの JavaSpaces 実装) を検討することをお勧めします。それはあなたができるようになります：

  • メッセージの FIFO 順序付け (それが重要な場合) (ただし、パフォーマンス コストがかかります)。
  • サブミリ秒のトランザクション グリッド更新。
  • そのキューイング API を使用する場合は、その上に構築された JMS 実装が付属しています。と
  • メッセージはクラスごとに定義されているため、適切な操作を読み書きするだけです。

GigaSpaces (および本格的なグリッド/クラスタリング テクノロジ) は、適切に拡張できます。パブリッシュ/サブスクライブ (すべてのリスナーがメッセージを受信するため、通常は必要なものではないため) または要求/応答 (キューがブロックされていないことを確認する必要があるため) でスケーリングしない純粋なキューイング ソリューションよりもはるかに優れています。悪いメッセージ)。

サーバーが使用しているテクノロジーについては言及していません。Javaなら大丈夫です。そうでない場合は、もう少し面白くなります。その場合は、Google Protocol Buffersを使用して何かを構築することを検討することをお勧めします。これは高性能のバイナリ交換形式であり、Java、C++、およびおそらく他のプラットフォームでサポートされています。

個人的には、Web サービスはトランザクショナルではないため (分散トランザクションに登録できないという意味で)、Web サービスの大ファンではありません。それはあなたにとって問題になるかもしれませんし、そうでないかもしれません。さらに、異なるテクノロジ スタック (Java と .Net など) 間の相互運用性には、依然として問題があります。

于 2009-02-12T05:41:27.567 に答える
0

そのためにリーダーとユーザーのHTTPに従うことができます:)

たとえば、AJAX API では、JSON と組み合わせて使用​​します (またはプレーンな JavaScript ですか?)

ここに例があります。

次のクエリの場合:

http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=hello%20world&langpair=en%7Cit&callback=foo&context=bar

完全な出力は次のとおりです。

HTTP/1.0 200 OK
Date: Thu, 12 Feb 2009 05:13:31 GMT
Content-Length: 97
Content-Type: text/javascript; charset=utf-8
Expires: Thu, 12 Feb 2009 05:13:31 GMT
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
X-Backend-Content-Length: 16
X-Embedded-Status: 200
X-Content-Type-Options: nosniff
Server: GFE/2.0

{"responseData": {"translatedText":"ciao mondo"}, "responseDetails": null, "responseStatus": 200}

もちろん、テストは非常に単純ですが、Java を使用した実装はこれほど単純ではありません。

もちろん、プロジェクトのニーズ、セキュリティ、アクセス制御などによって異なりますが、HTTP を使用することで、十分にテストされたプロトコルを中継できます。

于 2009-02-12T05:22:08.347 に答える