For very large numbers of market subscriptions over websocket, are there any per-SID limits I should bear in mind that could be triggering reconnects? For the same framework and base code, there's a large discrepancy between Kalshi and Polymarket connection stability that I cannot nail down, though from time to time I do see an explicit code=25, "Subscription buffer overflow"
For very large numbers of market subscriptions over websocket, are there any per-SID limits I should bear in mind that could be triggering reconnects? For the same framework and base code, there's a large discrepancy between Kalshi and Polymarket connection stability that I cannot nail down, though from time to time I do see an explicit code=25, "Subscription buffer overflow"
Does anyone know the max number of event tickers you can pass to Get Events? I assume you can't pass like, a gajillion event tickers theres probably some limit right?
Does anyone know the max number of event tickers you can pass to Get Events? I assume you can't pass like, a gajillion event tickers theres probably some limit right?
I'm sure there's some practical limit but you'd have to probe to find what it is. Could probably do it pretty simply
I'm sure there's some practical limit but you'd have to probe to find what it is. Could probably do it pretty simply
But I'd imagine you'd run into other problems with client side caching that would be a bigger problem before you found some hypothetical API limit
But I'd imagine you'd run into other problems with client side caching that would be a bigger problem before you found some hypothetical API limit
Found this in Changelog just now, from mid-June: "Sanity limits enforced on orderbook subscriptions: Max 500k market subscriptions per session. Max 10k/s commands per second enforced."
Found this in Changelog just now, from mid-June: "Sanity limits enforced on orderbook subscriptions: Max 500k market subscriptions per session. Max 10k/s commands per second enforced."
The limiting constraint will be how long your URL can be and this is constrained by middleware such as CloudFront. When they were using CloudFront, that was what limited number of tickers in a query string (the maximum CloudFront URL length is 8,192 bytes). I don't know what the limit might be with the new load balancer configuration.
The limiting constraint will be how long your URL can be and this is constrained by middleware such as CloudFront. When they were using CloudFront, that was what limited number of tickers in a query string (the maximum CloudFront URL length is 8,192 bytes). I don't know what the limit might be with the new load balancer configuration.
makes sense, Im just using it to backfill data so I'll be passing blocks of some small n tickers anyway
makes sense, Im just using it to backfill data so I'll be passing blocks of some small n tickers anyway
just wanted to make sure it wasn't limited to like 10, or something
just wanted to make sure it wasn't limited to like 10, or something
There might be some constraint in the Kalshi back end that hits before you hit a URL length limit, but last time I poked at this, I found that was not the case.
There might be some constraint in the Kalshi back end that hits before you hit a URL length limit, but last time I poked at this, I found that was not the case.
ive subed 10000 before, but you cant handle it. produced will outpace consumer, etc
ive subed 10000 before, but you cant handle it. produced will outpace consumer, etc
I have seen more WS disconnects and other network IO problems today than usual.
I have seen more WS disconnects and other network IO problems today than usual.
getting some websocket issues
getting some websocket issues
+1
+1