Factors for POST Entities API Latency
Scenario: Loading data into the tenant by batches (POST /entities)
Baseline latency: 130 milliseconds
Factor | Baseline parameter value | One step increase from baseline | Average latency increase by 1 factor step, % from baseline | Average latency increase by 1 factor step in milliseconds | Max analyzed value |
---|---|---|---|---|---|
Simple attributes per entity | 100 | every 100 additional attributes | 4.6% | 6 | 300 |
Nested attributes per entity | 10 | every 10 additional nested attributes | 5.4% | 7 | 50 |
Request size per entity | 10 KB | every 10 additional KB | 6.9% | 9 | 40 KB |
Reference attributes per entity | 0 | each additional reference attribute | 7.7% | 10 | 5 |
RDM lookups per entity | 5 | every five additional RDM lookups | 23% | 30 | 30 |
Countries count* | 0 | each new country value | 54% | 70 | 2 different countries (for example, US and Canada) |
Crosswalks per entity | 10 | every 10 additional crosswalks | 61.5% (6% per 1 crosswalk) | 80 | 30 |
Batch size | 10 | every 10 additional entities in the batch | 960% (96% per additional entity in the batch) | 1250 (125 ms per 1 additional entity in the batch) |
50 |
- Simple address cleanser: If you do not use simple address cleanser, you add up 450 ms to the latency on average
- Address as a referenced attribute:
- Having at least one reference address per entity on average in the dataset adds up to 300 ms to the latency.
- Every additional address adds up to 3 ms on an average.
- Count of new events generated in the internal CRUD queue should also be used as a factor. Batch size of 10 entities per update will normally generate 10 events and this is considered a baseline, not impacting the latency. Every additional event generated say due to increased size of the batch or due to additional merges happening as result of the update, will increase latency by 138% per additional event on average. These 138% will include the 96% increase of the latency per batch increase + additional performance cost of 42%.