Background
There are 2 settings in the emitter – buffer option (default 10) and emit range (default 150). Buffer option is the number of events that have to pile up before the tracker makes a request. Emit range is the number of events that can be sent in one iteration of the emitter (basically at once).
If due to collector being down, 200 events pile up in the event queue on the tracker, the emitter will make 15 requests with 10 events and fire them at the same time to the collector (because emit range is 150 and buffer size is 10 so max 10 events fit in one request => 15 requests).
Problem
The goal of making parallel requests is to send the events to the collector faster. However, after doing some tests, this does not seem to be the case in practice – sending 500 events in batches of 25 per request takes around the same total time to finish when making requests in parallel as it does when making requests serially.
Moreover, making requests in parallel increases the likelihood of duplicate events ending up in the warehouse. If there is a problem with the network connection while the requests are made, more events will be resent. Also making multiple requests at once increases the chance of network failures on weaker connections.
Suggestion
The suggested approach is to:
Make requests serially. Adapt the NetworkConnection to receive one request at a time.
Change the semantics of the buffer option and emit range so that buffer option is the minimum number of events that have to pile up before making a network request, and emit range is the maximum number of events that can be sent in a single request to the collector (may be larger than buffer option in case of events piling up in the event queue due to previous failed requests).
Background There are 2 settings in the emitter – buffer option (default 10) and emit range (default 150). Buffer option is the number of events that have to pile up before the tracker makes a request. Emit range is the number of events that can be sent in one iteration of the emitter (basically at once).
If due to collector being down, 200 events pile up in the event queue on the tracker, the emitter will make 15 requests with 10 events and fire them at the same time to the collector (because emit range is 150 and buffer size is 10 so max 10 events fit in one request => 15 requests).
Problem The goal of making parallel requests is to send the events to the collector faster. However, after doing some tests, this does not seem to be the case in practice – sending 500 events in batches of 25 per request takes around the same total time to finish when making requests in parallel as it does when making requests serially.
Moreover, making requests in parallel increases the likelihood of duplicate events ending up in the warehouse. If there is a problem with the network connection while the requests are made, more events will be resent. Also making multiple requests at once increases the chance of network failures on weaker connections.
Suggestion The suggested approach is to:
NetworkConnectionto receive one request at a time.Same issue on the iOS tracker.