Closed radiantstatic closed 3 months ago
At my organization we are using the Split Synchronizer with Redis in conjunction with the Node JS SDK. Despite offloading the synchronizer services, we are still seeing a dramatic increase in memory usage over time. Is there a preferred configuration that should be followed when using this that limits this? Based on profiling it appears to point to the caching occurring with the ImpressionObserver here: https://github.com/splitio/javascript-commons/blob/4d46ac0f4c1e8927a70034ba619c6112599fd3cf/src/trackers/impressionObserver/ImpressionObserver.ts#L10
Will this eventually cap out? If so, is there an expected or calculated cache size to refer to? Any help would be great.
Our current SDK configuration is:
const factory = SplitFactory({ mode: 'consumer', core: { authorizationKey: SPLIT_KEY, }, storage: { type: 'REDIS', options: { url: `redis://${SYNC_HOST}:${SYNC_PORT}/0`, }, } sync: { enabled: false, }, debug: 'ERROR', });
Some supporting evidence below:
Related with https://github.com/splitio/javascript-client/issues/803
At my organization we are using the Split Synchronizer with Redis in conjunction with the Node JS SDK. Despite offloading the synchronizer services, we are still seeing a dramatic increase in memory usage over time. Is there a preferred configuration that should be followed when using this that limits this? Based on profiling it appears to point to the caching occurring with the ImpressionObserver here: https://github.com/splitio/javascript-commons/blob/4d46ac0f4c1e8927a70034ba619c6112599fd3cf/src/trackers/impressionObserver/ImpressionObserver.ts#L10
Will this eventually cap out? If so, is there an expected or calculated cache size to refer to? Any help would be great.
Our current SDK configuration is:
Some supporting evidence below:![Screenshot 2024-04-10 at 10 02 28 AM](https://github.com/splitio/javascript-commons/assets/1668054/2f8771a6-262a-47e6-920a-aefd97d0c070)