Slowness after upgrading to 3.9 #295
Comments
|
Can you please share flamegraph SVGs of both releases and it will be helpful if you send diff as well using difffolded.pl |
|
Here's a zip containing flamegraphs for 3.8, 3.91, and 3.10 |
…SDK initialization (#296) ## Summary `OptimizelyConfig` object is generated when SDK is being initialized. This operation is heavy and blocks the SDK from initializing quickly. This object is only used when users explicitly access it using `get_optimizely_config` API call. This PR moves the creation of this object from SDK initialization to the actual API call. ## Test plan - Manually tested thoroughly - All unit tests pass - All FSC tests pass ## Issues fixes #295
|
@integralhero Re-opening after the auto-close from the PR merge. We just merged a change that we believe will improve performance on the initialization process for the SDK by deferring some data processing until it is explicitly accessed vs. running it on initialization. The data processing wasn't entirely new in 3.8 but we did expand the scope of data being processed in that version, so we suspect it would help address a change in that version. It's on Master now if you are able to validate off that whether you see an improvement in your test setup. |
|
Thanks so much for following up @Danny-Driscoll! Just tried it out and it looks fine. Cheers! |
|
Could we incorporate this in the next minor version bump? (not sure how y'all do releases) |
|
Yep, this will be released shortly in a new minor version. We just wanted to get some validation that it did indeed improve your observed performance before pushing it out. |
|
@integralhero We just released |
|
Thanks! Closing this issue |
Hey there, we recently bumped to 3.9 and noticed latency spike (~double) along a critical code-path. We have json schema validation disabled here for performance reasons.
As a comparison, here's a flamegraph I made where our code uses
Release version 3.8 of the ruby-sdk gem:
vs. 3.9.
I see a lot of cycles spent in
Optimizely::StaticProfileManager, possibly tied to this changeI was wondering if anyone's noticed something similar/ could give me more context on the change here and what we might be able to do to address the performance issues
The text was updated successfully, but these errors were encountered: