I was brainstorming about other workloads that we can add, similar to the API-x ones. I would suggest the following scenarios, open for discussion.
Static Assets (assets-x)
Serves the static files of a website, so this includes small JS/CSS/icon files. If possible, this should be a H1/2/3 workload, as this was the main reason to go with H2 in the first place.
Possible requests:
- GET a JS/CSS/HTML file (2-4 KB) with
Accept-Encoding: gzip, compression logic (penalties etc.) apply
- GET a non-compressible resource, e.g. an icon (with
Accept-Encoding: gzip header but without the penalty logic, server should be smart enough not to compress the content)
The sizing of such an instance depends on the traffic of the website, but is usually very small, so assets-2 or 4 may suffice. Maybe fetch all requests we have in static in one go as this is the typical behavior of a browser.
File Streaming (file-x)
Serves larger files such as videos or downloads. Has to support range requests as video players read them chunk-by-chunk and download managers need to be able to resume downloads.
Possible requests:
- GET a small range (e.g.
1-4096) of a large video file (latency matters as the users wants to directly see the video), can use the same Accept-Encoding: gzip trick as above
- GET a larger range in the middle of a large file (e.g. 2 MB). Range should be random to stress the server.
- GET a medium sized file, maybe 10 MB
As connections stay open for a while it is important that the server is actually async, so maybe use a small CPU count to enforce this (e.g. file-4).
API Gateway / Reverse Proxy (proxy-x)
The server is used to access other web servers. This would probably require a new test design and only a few frameworks may support this natively. So it's questionable whether this workload should be actually added.
Possible requests:
- GET a file from an upstream server (e.g. a static file, does not matter)
- POST content to an upstream server (e.g. a file)
Has the same async requirement as file streaming, so maybe also do just proxy-2.
I was brainstorming about other workloads that we can add, similar to the
API-xones. I would suggest the following scenarios, open for discussion.Static Assets (
assets-x)Serves the static files of a website, so this includes small JS/CSS/icon files. If possible, this should be a H1/2/3 workload, as this was the main reason to go with H2 in the first place.
Possible requests:
Accept-Encoding: gzip, compression logic (penalties etc.) applyAccept-Encoding: gzipheader but without the penalty logic, server should be smart enough not to compress the content)The sizing of such an instance depends on the traffic of the website, but is usually very small, so
assets-2or4may suffice. Maybe fetch all requests we have in static in one go as this is the typical behavior of a browser.File Streaming (
file-x)Serves larger files such as videos or downloads. Has to support range requests as video players read them chunk-by-chunk and download managers need to be able to resume downloads.
Possible requests:
1-4096) of a large video file (latency matters as the users wants to directly see the video), can use the sameAccept-Encoding: gziptrick as aboveAs connections stay open for a while it is important that the server is actually async, so maybe use a small CPU count to enforce this (e.g.
file-4).API Gateway / Reverse Proxy (
proxy-x)The server is used to access other web servers. This would probably require a new test design and only a few frameworks may support this natively. So it's questionable whether this workload should be actually added.
Possible requests:
Has the same async requirement as file streaming, so maybe also do just
proxy-2.