...
At ten times its expected peak production load (750 RPM), 95% of requests to /commerce/baskets/ complete in 1900 ms. At ten times their expected peak production load (30 RPM), 95% of requests to /api/v2/payment/processors/ complete in 780 ms, 95% of requests to /api/v2/baskets/ complete in 590 ms, 95% of requests to /payment/cybersource/notify/ complete in 1700 ms, and 95% of requests to /api/v2/baskets/:id/order/ complete in 760 ms.
Errors begin to appear Endpoints performing fulfillment operations start throwing errors at approximately 800 RPM, when endpoints performing fulfillment operations start waiting for significant periods of time on the enrollment API.
Results
Below is an overview of web transaction response time for the ecommerce service at increasing levels of load:
...
Errors begin to appear at approximately 800 RPM, when calls to external services (i.e., the enrollment API) made by endpoints performing fulfillment operations appear to start piling up:
Enrollment API response times start to climb dangerously high at 800 RPM:
appear to remain roughy constant at 100 ms, irrespective of load:
Endpoints which don't rely on the enrollment API scale better than those which do:
Bonus: The payment flow is capable of handling load significantly higher 30 RPM. Below is an overview of the CyberSource notification view's response times at 150 RPM:
...