Python Interactive Brokers IB API非常非常慢

Question

我正在尝试新的Python Interactive Broker API，但我在第一步遇到了一些严重的速度问题...

下面的代码（见下文）重复了两次

0:00:08.832813直到数据被接收完毕

0:00:36.000785直到应用程序完全断开连接。。。

为什么这么慢？最好的加速方法是什么？

from ibapi import wrapper
from ibapi.client import EClient
from ibapi.utils import iswrapper #just for decorator
from ibapi.common import *
from ibapi.contract import *
import datetime
from datetime import timedelta


class DataApp(wrapper.EWrapper, EClient):
    def __init__(self):
        wrapper.EWrapper.__init__(self)
        EClient.__init__(self, wrapper=self)

    @iswrapper
    def historicalData(self, reqId: TickerId, date: str, open: float, high: float,
                            low: float, close: float, volume: int, barCount: int,
                            WAP: float, hasGaps: int):
        super().historicalData(reqId, date, open, high, low, close, volume,
                                barCount, WAP, hasGaps)
        print("HistoricalData. ", reqId, " Date:", date, "Open:", open,
               "High:", high, "Low:", low, "Close:", close, "Volume:", volume)

    @iswrapper
    def historicalDataEnd(self, reqId: int, start: str, end: str):
        super().historicalDataEnd(reqId, start, end)
        print("HistoricalDataEnd ", reqId, "from", start, "to", end)
        print(datetime.datetime.now()-startime)
        self.done = True # This ends the messages loop - this was not in the example code...

    def get_data(self):        
        self.connect("127.0.0.1", 4002, clientId=10)
        print("serverVersion:%s connectionTime:%s" % (self.serverVersion(),
                                                self.twsConnectionTime()))

        cont = Contract()
        cont.symbol = "ES"
        cont.secType = "FUT"
        cont.currency = "USD"
        cont.exchange = "GLOBEX"
        cont.lastTradeDateOrContractMonth = "201706"
        self.reqHistoricalData(1, cont, datetime.datetime.now().strftime("%Y%m%d %H:%M:%S"),
                               "1800 S", "30 mins", "TRADES", 0, 1, [])
        self.run()        
        self.disconnect()
        print(datetime.datetime.now()-startime)

global starttime
startime = datetime.datetime.now()
DA = DataApp()
DA.get_data()

我还试图在后台持续运行它，以便只在运行时提交请求

def runMe():
    app.run() # where run() has be removed from the class definition

import threading
thread = threading.Thread(target = runMe)
thread.start()

但速度也非常慢。有什么建议吗

Answer 1

app。run（）是一个无限循环，而是一个应用程序。done==False，但当应用程序运行时，它不会立即停止。完成设置为真。（我不知道为什么）。

我所做的是编写一个新方法，而不是使用app。运行（）。

以下是我的解决方案：

import time
from ibapi import (decoder, reader, comm)

并将此函数放入您的客户端类中。

def getMessage(self, wait=3):
    # wait 3 secs for response to come in
    time.sleep(wait)
    # get everything in app.msg_queue
    while not self.msg_queue.empty():
        text = self.msg_queue.get(block=True, timeout=0.2)
        fields = comm.read_fields(text)
        self.decoder.interpret(fields)

用法很简单，只需用app.getMessage（）代替app.run（）

Answer 2

当前的API（2019年5月）通过移除@BenM在其回答中提出的recvMsg中的锁，提高了速度。但是，根据请求的类型，它仍然可能很慢。

删除大部分日志记录会有所帮助，可能是因为某些msg类型相当大。我最初尝试使用日志记录库将其过滤掉，但从速度上看，完全删除代码效果更好，我把这归因于在传递到日志记录之前生成更大字符串所需的额外处理。

用deque替换Queue：在客户机中替换队列可能也值得。py带有一个集合。因为deque是

队列与deque速度比较

Answer 3

我建议您在ibapi模块的connection类中修改连接套接字锁。该建议来自github上的何世明；如果您有权访问私人互动经纪人回购协议，您可以访问此处的讨论https://github.com/InteractiveBrokers/tws-api/issues/464

我这样做了，它显著提高了性能。

和信明建议您减少套接字锁对象的超时时间，该对象在每次发送或接收消息时都会调用。要修改套接字锁，请转到ibapi的网站包文件夹，并在connection.py内修改连接函数，将“self.socket.settimeout（1）”更改为“self.socket.settimeout（0.01）”。这是我有的版本的connection.py第48行。

如果你看不到何世明的帖子，我会把它放在这篇帖子的底部。

替代选项：另一个有趣的解决方案是利用异步事件循环来实现异步事件循环。我还没有这样做，但看起来很有希望。参见Ewald放在一起的示例https://github.com/erdewit/tws_async

何世明评论：

Connection/ibapi/Connection的实现。py在sendMsg和recvMsg中共享一个锁对象。既然连接，自我。插座settimeout（1）被调用，因此是底层的self。插座recv（4096）每秒仅超时一次。

这种实现会造成性能问题。由于锁是共享的，所以套接字在接收时无法发送数据。在接收的消息长度小于4k字节的情况下，recvMsg函数将在释放锁之前等待1秒，从而使后续的sendMsg等待。在我的实验中，大多数消息似乎都小于4k字节。换句话说，这规定了每秒一个recvMsg的上限。

有一些策略可以缓解这种情况。一个可以将接收缓冲区减少到一个比4k少得多的数字，或者将套接字超时减少到0.001秒左右，以减少阻塞。

或者根据http://stackoverflow.com/questions/1981372/are-parallel-calls-to-send-recv-on-the-same-socket-valid，套接字本身实际上是线程安全的。因此不需要锁。

我尝试了所有三种策略。移除锁效果最好。以类似的方式将超时时间减少到0.001。

我只能担保linux/unix平台，而且我还没有在Windows上尝试过。你会考虑改变实施方式来改进这个吗？