By default, all Split SDKs have default configuration that allow them to process 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 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 impressions per minutes that are higher than 30k, for example, 60k, then we need to update the parameters below:
impressionsRefreshRate = 20
impressionsQueueSize = 70k
Its always better to provide more buffer for the SDK to handle the actual load.
Note: If the Queue size is reached, the SDK will attempt to post its content 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 become full, however, in the cause where the load is higher than it could handle, it is always detecting that the queue is full and always 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 creation rate and make sure the SDK is configured to handle the load successfully