Increased API Calls to download_config_specs Endpoint After Updating Statsig Ruby Client

[kheraankit]

Hello Statsig Team,

We recently upgraded our Statsig Ruby client from version 1.25 to 1.32 and observed a significant increase in calls to the https://api.statsigcdn.com/v1/download_config_specs/ endpoint. This change has raised concerns about potential impacts on our application's performance and the efficiency of our interaction with Statsig's services. We would like to understand if the updates between these versions have introduced changes in how the client interacts with Statsig servers, particularly regarding configuration spec downloads or any related behavior that might explain this increase in API calls.

Could you please provide insights or clarifications on any changes in the SDK's behavior related to server communication or configuration updates from version 1.25 to 1.32? Your assistance will help us ensure optimal performance and effective use of the Statsig service.

Thank you for your support.

Best,
Ankit

[tore-statsig]

I think its not an "increase" you are observing, but a net new endpoint - we switch from hitting https://statsigapi.net/v1/download_config_specs to https://api.statsigcdn.com/v1/download_config_specs/ in v1.29.0

The default polling interval (10s) remains the same. My guess is if you chart out requests to each of those, the volume stayed the same

[kheraankit]

Thanks for the prompt response. I don't have 1:1 charting available but it seemed like new client was making additional calls, this was just based on a few traces where we observed the new client making the call to statsig vs old not. We saw a spike in latency on our side after bumping the SDK version so we had to revert back 1.25 version

[tore-statsig]

Interesting, thats certainly not expected. I believe latency was supposed to be on par, but moving to the CDN had implications on reliability more so than latency. Its possible if you were in the same region as one of our existing services, the CDN approach had higher latency. But was this really problematic for your integration? On the first initialization, that call is blocking, but after that the call happens in the background and should not impact latency on gate/experiment checks, for example.

We also introduced a number of optimizations in v1.32.0 which improved local evaluation performance by ~50%, so I hope you can take advantage of those improvements as well