I noticed that if I submit, say, five history data look up requests in rapid succession on the same socket, IQConnect will execute them one at a time in a serialized fashion. Even if I send all five requests together, IQConnect will not start processing all of them at the same time.

I can tell this because the responses come back like this: (Long Pause) Response 1 (Long Pause) Response 2 (Long Pause) Response 3 (Long Pause) Response 4 (Long Pause) Response 5, as opposed to: (Long Pause) Response 1 Response 2 Response 3 Response 4 Response 5, as you would expect if all the requests were submitted at approximately the same time.

But, I did notice that if I submit the five requests each on their own connection to the IQConnect history service, they will all complete at approximately the same time (indicating that they are submitted in parallel, as I hoped).

Given that IQFeed has been designed to handle multiple connections and application instances on a single machine in this way (ref: http://forums.dtn.com/index.cfm?page=topic&topicID=3156), I updated my application to use a number of sockets to submit history data requests, rather than just one.

This was working fine for a while this afternoon, until I started getting the following error:

'Could not connect to History socket.'

Am I exceeding some connection rate limit behind the scenes?

While I was debugging my application, I may have caused a lot of connections to be created and torn down (more than would be typical in normal use). This was happening because I would start 10-50 connections every time the application starts up, and while debugging I frequently need to restart the application.

I can work on implementing some local rate limiting to prevent tripping whatever the limit is, but I'm not sure where the "goal posts" are.

-Joe

Joe, that error is returned anytime IQConnect cannot connect to the history servers. It is theoretically possible for you to hit a rate limit but it wouldn't be anything specifically in IQConnect or the servers. It would most likely be something within windows (IQConnect trying to allocate resources for a new socket connection to the servers and being unable to do so).

I would expect that about 10 simultaneous history requests is going to be the upper end of how many you can run at one time and still get increased performance. In general, you will probably either be hitting a bandwidth limit on your machine or a context switching limit on your machine that will degrade your performance beyond that point.

So there are rate limits? Can you share what they are?

At the time, my machine was very lightly loaded and shouldn't have been receiving any out of resource errors. I actually also checked to see if there were an excessive number of sockets stuck open at the time (potentially causing a available port starvation problem), but didn't find anything out of the ordinary.

BTW -- I have tested up to 50 simultaneous history requests and found a nearly linear improvement in performance up to that level. I have not tested more sockets, so I am not sure how far that can be taken. However, at that level, CPU, memory and bandwidth utilization on my machine was low.

I should note that I was making relatively small historical data requests (<100 data points), which could be a factor.

-Joe

Joe, there are no limits built into the code of the feed or the servers currently. We do have plans to implement some reasonable limits in the future but those are only in planning stages at the present time.

Any limits I was referring to in the previous post would have been limits in the windows operating system and/or your operating environment (bandwidth/network equipment/etc).