Back to the landing page
Benchmark

10,000 virtual users.One single node.

A complete journey: visit the homepage, log in, create an event, reserve and buy a ticket, view the ticket and log out.

21 HTTP requests with sessions, data correlation and token processing in JavaScript.

18.59%
average CPU
2.13 GiB
average memory
1 node4 vCPU16 GB RAMGitLab CIA Go engine, designed to generate load efficiently.
Average process CPU
By load level, % of the node
0%25%50%75%100%15.20%2,500 VUs15.72%5,000 VUs18.59%10,000 VUs

100% is the full capacity of the four vCPUs.

Average process memory (RSS)
By load level, in MiB
05001,0001,5002,0002,500621 MiB2,500 VUs1,165 MiB5,000 VUs2,182 MiB10,000 VUs

In this experiment we ran 10,000 virtual users from a single node. Achievable capacity depends on the hardware, the script's complexity, the application's response times and network conditions. This test did not aim to determine Relampo's maximum capacity.

View the data as a table
Virtual usersAverage process CPUAverage process memory (RSS)
2,50015.20%621 MiB
5,00015.72%1,165 MiB
10,00018.59%2,182 MiB
Flow details
  1. Homepage
  2. Login
  3. Create event
  4. Reserve seat
  5. Buy ticket
  6. View ticket
  7. Logout

User journey

  • 21 HTTP requests covering a complete user journey.
  • Homepage and login, followed by event creation.
  • Seat selection and reservation.
  • Payment, ticket retrieval and logout.
  • Independent cookie sessions maintained throughout each virtual user's journey.
  • Per-VU credentials, assigned programmatically across 2,500 accounts. Higher loads reuse accounts through independent sessions.

Dynamic data & JavaScript

  • 17 extractors capture values from JSON, HTML and HTTP headers.
  • JSONPath and regular expressions extract tokens and identifiers.
  • Bearer authentication uses the token returned by the login API.
  • Request correlation passes event, seat, reservation and ticket IDs between steps.
  • Embedded JavaScript transforms a fresh reservation token using XOR and converts it to hexadecimal before submitting it to the payment flow.
  • HTML and URL decoding, plus explicit handling of payment redirects and dynamic parameters.

Context of the 10,000 VU run

Throughput, latency and errors refer to the 140-second inner window, unless stated otherwise.

2,153.47 RPS
during the inner window
7.59 s
p95 latency in that window
0
HTTP or transport errors during that window

p95 latency is measured end to end and includes the response time of the target Practice server.

Want access to the benchmark repository, including the comparison with other tools? Write to us and we will share it.

Request access