Response time
Response time needs a defined start and end. Fetching an API response and reaching a usable view measure different sections.
Response time describes the duration between a defined start and the corresponding result. The boundary must be named: for example, a request arriving at the server or starting in the browser.
Portal measurement boundaries
In a hypothetical portal, one measurement ends when the API response is fully received. Further steps may follow before the order list is displayed and usable. Those times are therefore not interchangeable.
Assessment needs the task, load and data volume alongside the measurement. Cache state and software version can also affect comparison. An average alone can hide slow cases. Without the same measured section, different times do not establish a reliable performance difference.
Sources
Related terms
- ThroughputThroughput describes work processed per period. It is neither the duration of one request nor the number of concurrent users.
- Legacy systemAn existing system still in use, with technical and business dependencies accumulated over time.
- Multi-tenancyMulti-tenancy supports separate customer or group scopes in one solution. A tenant is not automatically one person or one database.
- Browser cacheThe browser cache stores suitable HTTP responses for later use. Reuse and revalidation follow the applicable rules.
- Cache invalidationCache invalidation ends reuse of a stored copy under defined rules. The source record remains a separate concern.
- CachingCaching reuses stored data or results. Validity and the permitted user scope belong in the design.
Articles on this topic
Software Development with ASES
Custom software, web and mobile apps