By default, all Split SDKs have default configuration that allows them to process a heavy load of generated Impressions and Events. These config parameters values are documented in the help section of each SDK.
For example, if we take a look at the Java SDK, the Configuration section has the following parameters and their default values for posting impressions:
impressionsRefreshRate = 60 (seconds)
impressionsQueueSize = 30k
For the Impressions, the above settings means the SDK can handle up to 30k impressions (each impression is generated by one
getTreatment call) every 60 seconds.
If your code is generating more than 30k impressions per minute, then you will need to update these parameters. For example if you are generating 60k impressions per minute you could set:
impressionsRefreshRate = 20
impressionsQueueSize = 70k
It's always advisable to provide some buffer for the SDK to handle the actual load.
Note: If the Queue size is reached, the SDK will attempt to post its contents regardless of when the impression post thread runs.
The same concept is applied to the events created by using the SDK track() method. Here are the parameters corresponding to posting events:
eventFlushIntervalInMillis = 30000 (30 seconds)
eventsQueueSize = 500
The values above will allow the Java SDK to handle up to 1000 events per minute.
Important Note: What happen if the SDK cannot keep up with the incoming Impressions and Events load? The SDK will post the Queue content when it becomes full. However, in case where the load is higher than it can handle, it will be constantly detecting the queue is full and posting impressions. Once the impressions are posted, then it will clear the queue. In the meantime, when new impressions are created, they are not stored in the queue (since its full), and thus these new impressions are lost.
That is why it is important to verify these SDK configuration parameters values against your production Impressions and Events generation rate and make sure the SDK is configured to handle the load.