Performance and capacity | SFTP: transfers and batch operations

Concept and mechanism

Performance depends on latency, concurrency, buffers, CPU, and storage on both sides. Increasing outstanding requests can help on one path and increase memory or contention on another. Measure before and after under comparable conditions. In a model with sixty-four requests of 32768 bytes, the product is 2097152 bytes, or two MiB aggregate payload. The calculation includes neither time nor all process memory, so it is not measured throughput. The client bandwidth-limit option uses Kbit/s. With decimal units and no overhead, eight thousand Kbit/s equal one MB/s without guaranteeing that actual rate.

Guided application

Storage capacity also has several dimensions. Free bytes do not establish available inodes, space usable by the account, or quota headroom. If inodes are unavailable, creating a file can fail despite spare content space. Confirm the exhausted resource using authorized observations. The SFTP df command requires extension support; an unsupported-operation reply does not measure disk fullness. In a fictional case involving many small files, review ownership, retention, and consumption state before freeing capacity. Switching to another area also requires validating permissions, the consumer, and traceability rather than merely finding free space.

IN PRACTICE

64 × 32768 = 2097152 bytes; that does not equal bytes per second.

Common pitfalls

Concurrency as guaranteed improvement; payload as total RAM; bits as bytes; free space as every resource.

Related topics: Transport and server trust · Permissions and isolation · Batch and observable failures

Take this idea with you

Measure the limiting resource and keep units and scope explicit.

Create account

Reference: OpenBSD filesystem availability statistics · DR SFTP 2026-09; selected OpenSSH client, server and extension behavior