This is not fast enough moving forward, so I'm going to be overhauling the cache system to spread the load among even more threads
This is a good idea in an ideal world, but are the exchanges going to be okay with you hammering the APIs in this fashion? The (public) orderbook APIs are usually more forgiving, but still, especially if
cache daemons will need to be spawned for each user as well
I could see exchanges starting to blacklist IPs.
Also, if it wasn't clear from my first post (likely), I would be interested in beta testing when things get that far.
I've got things hashed out a bit more. The only APIs that I absolutely have to call even if nobody is using a certain exchange/tradepair is the trade data (to maintain my own tradebook on the back end fur the purpose of calculating slopes EMAs, etc against). Since these tradebook API calls are almost always public calls, and since they normally keep a large span of time, I can call these infrequently when the backend determines that nobody is running a plugin against a specific exchange/tradepair.
Regarding orderbooks, I have no need to keep a local copy, so i can spawn those daemons as needed (In real world, there will be many currency pairs at any given time that simply won't be being used).
So basically, Based on whether a tradepair is being used or not:
-tradehistory daemons will kick into either high speed mode or slow speed mode
-orderbook daemons will either kick on or off as needed
As far as private API calls, all I really need is balance data and a data on the user's current open orders, so these calls will just be treated normally as I do now.
I have already been in talks with many of the exchanges and they know what I am doing and have a list of the IP addresses the daemons run on. I'm quite positive that this shouldn't be a problem. If ever becomes one, I can simply launch daemons in different AWS zones to spread out among more IP addresses (though I don't foresee needing to happen at all)