Hi,

One of our clients has a use case when he requests several one-minute bars for a set of symbols. In this case we open a socket and send several requests, one after another:
- send a request for symbol A
- receive and process data for symbol A
- send a request for symbol B
- receive and process data for symbol B
etc.

When using API 4.9 we are able to get huge amount of symbol's data during one minute, we get a response from IQFeed immediately after the request (0-1-2 ms.).

When using API 5.1 we are not able to do this. When the request is sent, it takes about 300-700 ms. to get the first data message for the requested symbol. I.e.:
- send a request for symbol A
- waiting for a response from IQFeed (~500 ms)
- receive and process data for symbol A
- send a request for symbol B
- waiting for a response from IQFeed (~500 ms)
- receive and process data for symbol B
etc.

In this situation we are able to get data for only 2 symbols in a second, 120 symbols per minute... This is very slow...

1. Why does this happen? Is it possible to make it working faster, as it was before?
2. Are there any new limitations in new API 5.1?
3. How many simultaneous threads can request data from IQFeed at the same time? What is the limit? Which is the optimal number?

Note:
We use Java API, request type is "HIT".
We used "LookupClient.java" example from IQFeed SDK for testing.

Thank you.

Good morning XoCe,

While I would love to take credit for a 2 ms return on history, this is simply not possible for anyone. When you request data from us, we have to open a new socket connection. So the request to the server is sent and we verify the request and reply that the connection is accepted, this means that you are immediately out 2 times your ping at a minimum.

After that, your request is sent to the server, and the data is retrieved, that process is very quick, but it has to be counted, but then that data has to be sent back to you, so we have once again cost ourselves at minimum 2 times our ping.

So even the machine sitting down the street that might be lucky enough to have a 35 ms ping, would still incur a minimum time on a history request of around 150 ms. This has been how the product has always worked, but that said, we do allow for multiple sockets to connect to us at any given time, up to 15 concurrent connections.

So even if you are having a bad ping day, we'll say of 125, and you could process all the data coming in fast enough, there is nothing to stop you from pulling 30+ symbols a second (or 1800 per minute). But doing it with one socket, you are correct, if your customer had a ping of 100+ they are going to see exactly what you have mentioned above, but there is no way that I can think of that they would see anything different in 4.9 either.

Tim

Hi Tim,

Thank you for your answer.

Yes, it looks like you are right. We have missed that API 4.9 does not send the confirmation of the protocol before data (S,CURRENT PROTOCOL), so the first data message was just skipped when working under API 4.9. And of course every next bar after the first one was received in 0-1 ms.

Response time in API 4.9 is approximately the same as in 5.1...

Thank you for your help.

Glad we were able to get it worked out. Let me know if we can help further though.