FRAMEWORK BENCHMARKS / PROJECT LAB
Understand what each test does, what its response looks like and where to inspect the verification code.
These workloads isolate different parts of a web application. Select equivalent implementations and inspect their source before treating a ranking as a production prediction.
How measurements are collected ↗Return a freshly serialized object containing a message. This exercises routing, JSON encoding and HTTP response handling.
Inspect the verifier ↗application/json{"message":"Hello, World!"}Fetch one random World row by ID and serialize its id and randomNumber as JSON. Access the database for each request using the declared connectivity approach.
Inspect the verifier ↗application/json{"id":123,"randomNumber":456}Read the requested number of random World rows individually and return a JSON array. The queries parameter is constrained to 1–500. Published charts normally highlight 20 queries per request.
Inspect the verifier ↗application/json[{"id":123,"randomNumber":456}, …]Fetch random World records from an application-side cache and return an array. This is a separate workload from database reads; see the full rules for cache population and correctness.
Inspect the verifier ↗application/json[{"id":123,"randomNumber":456}, …]Read all fortune messages, add a new message at request time, sort by message text and render a server-side HTML template. Escape untrusted HTML and preserve UTF-8.
Inspect the verifier ↗text/html; charset=UTF-8<table>
<tr><th>id</th><th>message</th></tr>
…
</table>Read random World rows, change their randomNumber values, persist the updates and return the modified rows as JSON. Query count controls how many rows are updated.
Inspect the verifier ↗application/json[{"id":123,"randomNumber":789}, …]Return the fixed text response. HTTP pipelining and larger load levels exercise the HTTP stack with minimal application work.
Inspect the verifier ↗text/plainHello, World!