Ecommerce Load Test
Download as PPTX, PDF
0 likes1,925 views
This presentation can serve as a template for presenting load testing results with team members. In particular this presentation differentiates performance into two discrete areas: throughput and response time.
Ecommerce Load Test
- 1. Ecommerce v2 StackLoad TestTesting Performance through response time and throughputStephen Rylander
- 2. Session Basis for Load TestWhat is Performance?Page ViewsPhysical TiersResponse TimesIIS CountersPreliminary Findings
- 3. Basis for load test
- 4. PurposeGenerate baseline of site by.increasing load on the infrastructure and application in aControlled and predictable manner
- 5. SpecificsThe ramp up4 steps250 ::: 6:14 min500 ::: 8:07 min1000 ::: 8:53 min2000 ::: 11:45 min
- 6. Location AlertSites cloud based (Amazon Web Services) load test infrastructure
- 10. Dlp page 2
- 11. Post filter / get filtered dlp
- 13. Dlp (t-shirt)
- 14. Dlp (bedding)
- 15. Pdp bedding set
- 16. Add to cart / get View cart
- 17. Continue to checkout/get sign in page
- 18. Post checkout start/ get address info (guest)
- 19. Post address / view payment info
- 20. Post payment / view confirmation ENDWhat is Performance?
- 21. 2 ways to 馨艶温壊顎姻艶
- 22. 1 - ThroughputThroughputRequests per secondTransactions per minuteExecutions per click
- 23. 2 - Response Response TimeDuration of a taskSeconds per clickPage loadDNS lookupLength of time between <click> and seeing page
- 24. TogetherThe system should handle 3M page views an hour with each page returning in less than 2.5 seconds.
- 25. Thinking about MeasurementsAveragesCasual statisticNot bad for short periodsHeavy variance maskedCan hurt customerPercentilesDifferent way of viewingLike a standardized testHome page should load in under 2 seconds for 95% of executions.
- 26. Our customers feel the variance, not the mean.GE Six Sigma
- 27. Shoppers vs. Page Views11/146PM166,397 page views = 30K visitors/hour (sitetracker)7 PM 172,716 page views = 31K visitors/hour (sitetracker)Shoppers/Visitorsis only a business concept applied to historical averaged user behavior. It is a predictive tool not a capacity planning tool.
- 28. Page viewsThe numbers via throughput
- 29. Reported
- 30. Real FeelThis year high: NK /hour
- 31. Response Time
- 34. Wednesday Nov. 11 ::: 123K page views/hour
- 35. Queuing?
- 36. Queuing?
- 37. Trending over position in test 1
- 38. Trending over position in test 2
- 39. Trending over position in test 3
- 40. Web counters
- 41. Reqs QueuedReq/secReqs/sec: avg. 49; max 117Queued: avg. 273; max 1138
- 42. Reqs currentReqs queuedReqs executing
- 43. Servers
- 44. WebTrans02
- 45. WEB02
- 46. Take aways
- 47. What we saw~20% load increase over our busiest hour this yearAt peak ~10K orders/hourLinear scaling; linear slow downPhysical server capacity ok
- 48. ConcernsIIS queuing because ofDown stream servicesPayment, inventory, etcConnection limitsSQL connection limits per/poolWeb server worker thread starvation
- 49. What weve been doingAdding more web tier capacitySplitting more app poolsBumping up worker processes in external web services
- 50. Next stepsVerifying new web tier and services capacityAnalyzing daily performance monitorsInvestigate downstream connections
- 51. endThanks.