Deployed 012bf45 with MkDocs version: 1.6.1

This commit is contained in:
2026-10-21 02:09:43 +00:00
parent 0086e55429
commit e4914487fc
4 changed files with 11 additions and 4 deletions
+1 -1
View File
@@ -4118,7 +4118,7 @@ configured proxy providers), or a <code>provider:region</code> form. See
</tr>
<tr>
<td><code>--download-processes N</code></td>
<td>Opt-in: split a large segment batch across <code>N</code> download processes, each with its own worker pool. A single process tops out around 1.3 Gb/s (Python interpreter limit); <code>2</code> reaches 2.5GbE line rate on fast CDNs. Only engages for batches of 24+ segments. Ignored while <code>--speed-limit</code> (or serve's <code>global_speed_limit</code>) is set: the cap is one shared budget, which extra processes cannot share, so the download stays in a single process. Also ignored when the service HTTP session carries state a child process cannot rebuild, such as a custom TLS adapter. The download stays in a single process instead of running with the wrong settings. Default <code>1</code>.</td>
<td>Opt-in: split a large segment batch across <code>N</code> download processes, each with its own worker pool. A single process tops out around 1.3 Gb/s (Python interpreter limit); <code>2</code> reaches 2.5GbE line rate on fast CDNs. Only engages for batches of 24+ segments. Ignored while <code>--speed-limit</code> (or serve's <code>global_speed_limit</code>) is set: the cap is a per-job budget, which extra processes cannot share, so the download stays in a single process. Also ignored when the service HTTP session carries state a child process cannot rebuild, such as a custom TLS adapter. The download stays in a single process instead of running with the wrong settings. Default <code>1</code>.</td>
</tr>
<tr>
<td><code>--continue-downloads</code></td>