4 Commits

Author	SHA1	Message	Date
dillard	9b85221e50	Read ahead: a plan that cannot be made leaves the restore to the usual reads; only a whole buffered SFTP packet counts as an answer waiting	2026-10-19 08:54:13 +02:00
dillard	c95f552cc6	Read ahead over SFTP: one connection with 32 requests in flight by default, more with restore_sftp_connections; a Storage Box gets slower with parallel readers	2026-10-19 07:46:12 +02:00
dillard	43a71684f9	Read ahead over SFTP: take answers phpseclib has read already instead of waiting up to 10 s on the socket	2026-10-19 05:28:26 +02:00
dillard	ccbbf01c54	Full restore over SFTP: read packs ahead on four connections at once ... A restore read one pack at a time over one SFTP connection, which over a long line is bound by the round trip and by what one TCP connection gets: about 2-3 MiB/s from a Hetzner Storage Box to Canada, with PHP mostly waiting. Repository::restore() now first lists the ranges of packs the restore needs, in order (ReadAheadPlan), and the location reads them ahead into unlinked files in a spool folder in the target (IReadsAhead). Over SFTP, SftpRangeFetcher does that on four connections of its own, 16 requests in flight each, taking the answers of whichever connection has one. A range that fails, a damaged copy, or a blob that moved since the plan is read the usual way, which reports what is wrong. Other locations restore as before. On a test line with 120 ms RTT and 0.2% loss, a 1.6 GiB restore went from 5.1 to 17.8 MiB/s, all files identical.	2026-10-19 01:40:49 +02:00