Accelerate the Value of Data

Factors for POST Entities API Latency

Scenario: Loading data into the tenant by batches (POST /entities)

Baseline latency: 130 milliseconds

Table 1. API Latency Details
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
Two other factors to consider for POST API latency include:
  • 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%.