4 ms·
A significant problem with traffic replay in a few cases I've considered in the past is HTTP POSTs and usage of headers. For most, logging that extra info is no
by bizzleDawg 6y ago
A significant problem with traffic replay in a few cases I've considered in the past is HTTP POSTs and usage of headers. For most, logging that extra info is not realistic and rules out traffic replay as a possibility for simulating realistic load.
Quite often, everyone one the team will already know which endpoint(s) are slow or unscalable. In that case, it is possible to set up a much less realistic load test in order to generate some flame charts of the problematic area. It can be more pragmatic than having to maintain what is essentially a new integration test suite as the author mentions.
- rlonn 6y agoExactly what I just wrote in another comment :) Start with simple, "unrealistic" load tests of suspected hot paths and you're likely to get very good ROI on the hours you spend.
- onefuncman 6y agothe adage from service level perf testing (you don't know what's really slow/brittle until you measure...) holds equally well at the systems level. Yes, you can probably identify decent areas to improve by guessing, but you'll never find your blind spots...