5 ms·

I'm actually curious about why it makes sense to load test an entire web UI (which is what this post seems to be suggesting). In my experience, it was enough t

by safog 6y ago

I'm actually curious about why it makes sense to load test an entire web UI (which is what this post seems to be suggesting). In my experience, it was enough to load test individual back end APIs to figure out load profile for each API and use that to scale your h/w and serving HTML is rarely a bottleneck. This is complicated if you have a big monolith with a diverse traffic pattern - so knowing your auth API can support up to 1k QPS on your existing h/w is not super helpful for example. There are ways to work around this, but kind of complicated to enumerate all the scenarios in a comment. This still needs some sort of state building, but this should be a lot easier than setting up state using a UI / clicking buttons.

csours 6y ago
It really depends on what you're trying to test. You can hit the backend to prove stability of those elements, but you can't hit the backend to show what the user will experience while using your website.
- safog 6y ago
  Does it change meaningfully under load? As long as the API p50 / p95 latencies are what you expect, the HTML generation / rendering is rarely a problem.
  - csours 6y ago
    You can't know until you test.
    - safog 6y ago
      That's a bit handwavey. Experience plays a part here and I've at least never seen a scaling issue where the root cause is not some form of API latency. Most of the raw HTML generation, rendering is done by frameworks and browsers respectively and they're pretty standard / efficient pieces of software.
      - csours 6y ago
        > I've at least never seen a scaling issue where the root cause is not some form of API latency. I guess we all come at this with our own assumptions. When I think about testing, I'm also thinking about the base experience, not just adding resources and adding load.
edoceo 6y ago
Also, testing from the App layer let's you capture the latency between services too so you can get performance of that "last metres" of code.
awinter-py 6y ago
yeah if you can narrow down your 'unit of scale' life gets a lot better 'load clarity' one of the good reasons to break out into a multi-service arch

by safog 6y ago

csours 6y ago

It really depends on what you're trying to test. You can hit the backend to prove stability of those elements, but you can't hit the backend to show what the user will experience while using your website.

safog 6y ago
Does it change meaningfully under load? As long as the API p50 / p95 latencies are what you expect, the HTML generation / rendering is rarely a problem.
- csours 6y ago
  You can't know until you test.
  - safog 6y ago
    That's a bit handwavey. Experience plays a part here and I've at least never seen a scaling issue where the root cause is not some form of API latency. Most of the raw HTML generation, rendering is done by frameworks and browsers respectively and they're pretty standard / efficient pieces of software.
    - csours 6y ago
      > I've at least never seen a scaling issue where the root cause is not some form of API latency. I guess we all come at this with our own assumptions. When I think about testing, I'm also thinking about the base experience, not just adding resources and adding load.

edoceo 6y ago

Also, testing from the App layer let's you capture the latency between services too so you can get performance of that "last metres" of code.

awinter-py 6y ago

yeah if you can narrow down your 'unit of scale' life gets a lot better 'load clarity' one of the good reasons to break out into a multi-service arch