0

私は本質的にブラック ボックスであるデバイスを使用しており、その通信方法として知られているのは XML-RPC だけです。2 つのコマンドを次々と非常にすばやく実行する必要がある場合を除いて、ほとんどのニーズに対応しています。オーバーヘッドと RPC 応答の待機のため、これは期待したほど速くはありません。

私の主な質問は、この機能を可能にするために、このオーバーヘッドをどのように削減するかということです。明白な解決策が XML-RPC を捨てることであることは知っていますが、「サーバー」からの他のプロトコルの実装を制御できないため、このデバイスではそれが可能だとは思いません。これにより、MultiCall に有効な命令を追加できないため、MultiCall を実行することもできなくなります。MultiCall はサーバー側で実装する必要がありますか? たとえば、メソッド 1()、メソッド 2()、およびメソッド 3() がすべてサーバーによって既に実装されている場合、このコード ブロックはそれらすべてを 1 回の応答で実行するように機能する必要がありますか? ドキュメントには、サーバー側でコマンドを初期化する必要がある例が示されているため、これまでのテストではノーだと思います。

server=xmlrpclib.ServerProxy(serverURL)
multicall=xmlrpclib.MultiCall(server)
multicall.method1()
multicall.method2()
mutlicall.method3()
multicall()

また、xmlrpclib のソースを調べると、使用されているデフォルトのものではなく、「FastParser」への参照が表示されます。ただし、このパーサーをデフォルトで有効にする方法がわかりません。さらに、この回答に関するコメントには、一度に 1 文字ずつ解析することが記載されています。これは関連していると思いますが、この設定を変更する方法がわかりません。

4

1 に答える 1

0

要求または応答のバルク サイズが非常に大きい場合を除き、パーサーの変更がターンアラウンド タイムに影響を与える可能性はほとんどありません (CPU はネットワークよりもはるかに高速であるため)。

可能であれば、最初のコマンドからの応答を待たずに複数のコマンドをデバイスに送信することを検討してください。デバイスが一度に複数の要求を処理できる場合は、これが役立つ可能性があります。デバイスが要求を順番に処理するだけの場合でも、前の要求を処理した後に遅延がないように、デバイスで次の要求を待機させることができます。デバイスがこの方法でリクエストをシリアル化する場合、それはあなたができる最善のことです。

于 2012-07-24T00:38:24.180 に答える