How Stroppy Cloud works
You describe a database and a workload and press Launch. Stroppy Cloud brings up machines in your cloud, installs and tunes the database, drives the load and takes the machines down again. A 10-minute TPC-C run on one PostgreSQL machine takes about 19 minutes from launch to report. This page follows one.
Typical times for a 10-minute TPC-C run on one PostgreSQL machine. Pick a stage to jump to it.
What you describe
A database, a workload and machine sizes make a test. Describe each part once and reuse it; launch the test on its own, as a suite of variants or on a schedule. Hover a block for an example.
Overview
On the left is what you describe once and reuse across tests: databases and workloads. In the middle sit the test and the three ways to launch it, and on the right the report a run leaves behind. Hover a block for an example and details.
Machines come up in your cloud
Stroppy Cloud creates the network and machines in your cloud with your key, and an agent starts on each machine. The diagram shows where every part runs while the benchmark is on: Stroppy Cloud, Graphene and your cloud. Pick a step to follow a run through it.
Overview
Three zones: the Stroppy Cloud product (the console in your browser and the server), Graphene, which runs the pipelines, and your cloud with the stand. Each zone lists its dependencies underneath; hover a block to see what it depends on.
The database is tuned for its machine
The agents start the DBMS in containers, tuned for its machines; the cluster forms, and the stand passes its checks before any load.
- Every engine it deploys: PostgreSQL, OrioleDB, MySQL, MariaDB, CockroachDB, YDB and Picodata. On by default.
- Tuned for the CPUs, memory and disk, the node’s role, the topology and the load.
- A key you set yourself wins, key by key.
- The values a run used are in its report.
- Set the database to
stockto measure the engine’s own defaults.
| Setting | Stock | loweredraised, log scale | Tuned |
|---|---|---|---|
shared_buffers | 128 MB | ×128 | 16 GB |
effective_cache_size | 4 GB | ×12 | 48 GB |
max_wal_size | 1 GB | ×18.6 | 18.6 GB |
maintenance_work_mem | 64 MB | ×32 | 2 GB |
max_parallel_workers | 8 | ×2 | 16 |
effective_io_concurrency | 1 | ×200 | 200 |
random_page_cost | 4 | ÷3.6 | 1.1 |
checkpoint_timeout | 5 min | ×3 | 15 min |
The load runs while you watch
The stroppy runner drives the workload segment by segment: data load, warmup, then the load itself. You watch QPS, latency and logs in the console as it goes.
The longest stage: about 12 of the run’s 19 minutes. Keep scrolling and the clock runs through it.
The machines go, the report stays
The machines are removed unless you asked to keep the stand. The report stays.
One run answers one question
A suite asks several at once, and a schedule keeps asking. Both launch ordinary runs, each with its own report.
Suites
Run variants of a test in one launch: database versions, machine sizes, settings. The results land in one table.
Schedules
Launch a test or a suite on cron. Each launch adds a point to the history chart, so a slower version or setting shows up before your users notice it.
0 3 * * *Launch from CI, hear back by webhook
Everything the console does goes through a public REST API with an OpenAPI contract. A personal token launches a test from your pipeline; webhooks report each step of the run as it happens.
POST https://cloud.stroppy.io/api/v1/t/{tenant}/tests/{id}:launch
Authorization: Bearer <token>run.startedrun.stagerun.finished
- If a run stops early
run.failedrun.cancelled- For a suite
suite.startedsuite.cell_finishedsuite.finished