2

Python (サーバー) と Haskell (クライアント) の間のクロス言語プラットフォームとして、単純な Thrift サーバー ( http://thrift.apache.org/ ) を実行しています。送信する必要がある唯一のデータ構造は double の 3 タプルであるため、サーバー/クライアントの実装も非常に単純です。チュートリアルに従うだけで十分でした。

しかし、それは本当に、本当に遅いです！約 0.1 秒以下の時間が必要な場合、各サーバーの応答で約 0.5 秒の応答時間が得られます。

これをスピードアップする方法について誰かアイデアがありますか? 以下に、私の単純なサーバー実装を示します。

  1 import sys
  2 
  3 from vision import Vision
  4 from vision.ttypes import *
  5 
  6 from thrift.transport import TSocket
  7 from thrift.transport import TTransport
  8 from thrift.protocol import TBinaryProtocol
  9 from thrift.protocol.TBinaryProtocol import TBinaryProtocolAccelerated
 10 from thrift.server import TServer
 11 
 12 class VisionHandler:
 13   def observe(self):
 14     ret = Position()
 15     ret.x,ret.y,ret.z = (1,2,3)
 16     return ret
 17     
 18 ret = Position()
 20 handler = VisionHandler()
 21 processor = Vision.Processor(handler)
 22 transport = TSocket.TServerSocket(port=9090)
 23 tfactory = TTransport.TBufferedTransportFactory()
 24 pfactory = TBinaryProtocol.TBinaryProtocolFactory()
 25 
 26 server = TServer.TSimpleServer(processor, transport, tfactory, pfactory)
 27 
 28 print 'Starting the vision server...'
 29 server.serve()
 30 print 'done.'

クライアントは、実行してこのサーバーにクエリを実行するだけです

36   client = do
37     handle <- hOpen ("localhost", PortNumber 9090)
38     let binProto = BinaryProtocol handle
39     return (binProto, binProto)

その後

res <- Client.observe =<< client

私の知る限り、これはすべてかなり標準的なものです。なんでこんなに遅いの？？

ありがとう！

4

2 に答える 2

2

ソケット オプションに関する Ellioh の回答での素晴らしい提案は別として、問題の 1 つは、操作が少し小さく、ソケットを介して処理するには問題がないように見え、ほとんどの時間がネットワークや同様の待ち時間に費やされることです。通常、呼び出しをグループ化して、より多くのデータを転送し、各呼び出しでより多くの作業を実行しようとします。ネットワーク分散アプリでは粒度が非常に重要であり、優れたパフォーマンスを得るには適切な尺度を見つける必要があります。

于 2013-02-12T11:16:12.087 に答える
1

ほとんどの場合、ソケットのオプションが原因です。Thrift でソケット オプションを設定できるかどうかは覚えていませんがTCP_NODELAY、輻輳制御をオフに切り替えるように設定すると、問題が解決する可能性があります。

これが使用するコードと同じであれば、ソケットに簡単にアクセスできます。TSocket をサブクラス化してみてください。

このオプションは、サーバー側 (accept() から返されるソケット) とクライアント側 (クライアントによって作成されたソケット) の両方でデータを送受信するソケットに設定する必要があります。Thrift は遅くはないので、本当に巨大なものをシリアライズしていない限り、問題はシリアライゼーションにあるはずはありません。つまり、問題は「接続、データの送信、回答の取得」のすべてにあるということです。によってオフにされた Nagle アルゴリズムが原因であることはほぼ間違いありませんTCP_NODELAY。

于 2013-02-11T11:11:48.270 に答える