rqlite adds an INSERT benchmark with explicit batch controls

Requests per second and statements per second answer different questions when one HTTP request can contain a batch. rqlite 4.2.1, released on 10 November, introduces a simple INSERT-only benchmark that reports both. Its controls make batch size and transaction grouping explicit, which is necessary for interpreting the numbers it prints.

The tagged changelog attributes the tool to pull requests 373 and 374. The same release improves CLI authorization errors and removes unnecessary indentation from outgoing JSON. These are client-tool changes around the existing HTTP API, rather than new SQL capabilities in the server.

I value a small benchmark whose request construction is easy to inspect. The useful part is understanding which work a reported rate includes. A headline number without its batching and response checks would say too little about the database operation being measured.

One statement becomes a repeated request body

The rqbench entry point accepts a SQL statement as its positional argument. Its options include a target address, a request count, statements per request and an explicit-transaction choice. The defaults are 100 requests and one statement per request, with explicit transactions disabled.

The HTTP tester implementation prepares an array containing the supplied statement repeated according to the batch-size option. It serializes that array once into JSON and retains a reader over the resulting bytes. Each iteration seeks the reader back to its start before posting the request.

This gives the benchmark a stable repeated payload. It does not generate a different row value for each request. The SQL supplied by the user determines what repeated execution means for the table, including whether constraints permit the same statement to succeed repeatedly.

The transaction option adds ?transaction to the execution URL. That selects the server's request-scoped transaction behavior for the repeated statement array. The batch-size option and transaction option therefore describe separate choices. A request can contain several statements, and the flag determines whether the server treats that group as an explicit transaction.

Execution is sequential

The benchmark's run function calls the tester once per loop iteration. It does not launch concurrent workers. After each successful iteration, it adds the returned duration to an accumulated total. The printed total is that sum, and the rates divide request count and statement count by its seconds.

With batch size greater than one, the statement numerator is the request count multiplied by the batch size. This is why requests per second and statements per second can differ substantially without describing different runs. The tool reports two units for the same configured work.

The measured duration begins immediately before the HTTP POST and ends after the tester has received the response and checked its status. Individual database results remain unchecked because the implementation does not decode the response body. The number therefore needs a narrower interpretation than confirmed successful inserts per second.

The tool also returns an error on a failed HTTP exchange or a non-200 status. Those checks establish something useful about the transport, but the rqlite API can report statement errors within its JSON response. HTTP success alone does not establish that every repeated insert changed the database as intended.

I find this limit worth stating directly because the rate's numerator comes from configured work. Multiplying requested batches by their size describes submitted statements. It does not inspect returned rows-affected values or count successful inserts independently.

The first tool remains limited

The command exposes a transport option, but its implementation creates an HTTP tester and identifies transports other than HTTP as invalid. Its source does not provide a multi-transport benchmarking framework. It also does not print a latency distribution, since it accumulates durations rather than retaining a histogram of individual request latencies.

The address formatting in this initial HTTP tester includes an extra colon before the path. That makes the exact generated URL another implementation detail to inspect when using this release's tool. The release announcement establishes the addition of rqbench, but it does not supply benchmark results demonstrating a working run under every target configuration.

These observations keep the new utility in proportion. It is a short request generator with batch and transaction controls, not evidence of a particular throughput claim. No rate in the release notes establishes how a separate deployment performs.

Unauthorized responses become clearer in the CLI

The interactive client source now checks for HTTP 401 and returns an explicit unauthorized error. It performs that check in both the SQL request path and the JSON diagnostic-fetch path. Previously those paths could continue toward response decoding without identifying the authorization failure directly.

Outgoing statement JSON also uses ordinary marshaling instead of indentation. That removes presentation whitespace from a machine-consumed request without changing the statement array it represents. Together, these changes make client behavior more precise, while the new benchmark gives operators an inspectable starting point for repeated HTTP execution.