Ottimizzazione upload batch: trasferisci cartelle più veloce

La strategia di upload batch più veloce: impacchetta la cartella in un unico .zip (modalità store, nessuna compressione) e carica un singolo oggetto grande invece di migliaia di file piccoli. Una cartella di 5.000 file .jpg da 500 KB ciascuno totalizza 2,5 GB ma richiede 10-20x più tempo da caricare singolarmente rispetto a un singolo archivio da 2,5 GB, perché ogni file piccolo paga l'intero overhead TLS e HTTP. I servizi con supporto upload parallelo (HexaTransfer, Dropbox, rclone) aiutano quando molti chunk sono grandi. Anche i servizi senza parallelismo vincono sul throughput una volta che si combinano i file piccoli in un unico archivio. Aggiungi la deduplicazione dei file accidentalmente duplicati, elimina il disordine come .DS_Store e Thumbs.db, e finirai in una frazione del tempo naive.

Perché migliaia di file piccoli sono lenti

Ogni upload di file via HTTPS porta un overhead fisso: handshake TLS (riutilizzabile con keep-alive della connessione), header HTTP (~500 byte), acknowledgment del server e flush su disco lato ricezione. Per un file da 50 KB, quell'overhead può superare la dimensione del file stesso. Per un file da 500 KB, l'overhead occupa il 10-20% del totale dei byte sulla rete.

Moltiplicato per 5.000 file e hai bruciato metà del tempo su metadati invece che su payload. Per questo copiare una cartella grande con molti file piccoli su un dispositivo di archiviazione esterno è sempre più lento che copiare un unico archivio di dimensioni equivalenti.

Prima archivia, poi carica

Il singolo maggior acceleratore per gli upload di cartelle: comprimi prima in un unico .zip, .7z o .tar. Per contenuti già compressi (foto, video, documenti Office), usa la modalità store (nessuna compressione) — ottieni il vantaggio del raggruppamento senza il costo CPU. Per cartelle con molto testo (log, codice sorgente), usa la compressione predefinita per un reale risparmio di dimensioni.

Comandi:

• macOS/Linux: zip -0 -r archivio.zip cartella/ per nessuna compressione; zip -r archivio.zip cartella/ per la compressione predefinita.
• Windows: clic destro sulla cartella → Invia a → Cartella compressa (zippata). Oppure usa 7-Zip con Aggiungi all'archivio → Livello di compressione → Store.
• Cartelle grandi: tar -cf archivio.tar cartella/ (nessuna compressione) o tar -czf archivio.tar.gz cartella/ (gzip).

Deduplica prima di archiviare

Le cartelle accumulano file duplicati nel tempo. I progetti di design hanno "finale_v2.psd", "finale_v2_COPIA.psd", "finale_v2_BACKUP.psd" — stesso contenuto, nomi diversi. Una cartella da 20 GB può ridursi di routine a 12 GB dopo la deduplicazione.

Strumenti: fdupes (Linux), rmlint (Linux/macOS), Duplicate File Finder (macOS), dupeGuru (multipiattaforma). La maggior parte funziona hashando i file e segnalando gli hash identici. Esamina i risultati, elimina i duplicati, poi archivia.

Per i fotografi, il catalogo di Lightroom tiene già traccia delle foto uniche; esporta solo le selezioni flaggate invece di intere cartelle di acquisizione.

Salta il disordine del sistema operativo

Ogni cartella macOS accumula file .DS_Store (metadati nascosti). Ogni cartella Windows porta Thumbs.db. I file .directory di Linux appaiono da KDE. Questi non aggiungono nulla per il destinatario e gonfiano il conteggio dell'archivio.

Quando archivi su macOS:

zip -r archivio.zip cartella/ -x "*.DS_Store" "__MACOSX"

Su Windows via 7-Zip, escludi i pattern nell'interfaccia o da riga di comando con -xr!Thumbs.db -xr!desktop.ini. Per i trasferimenti in stile rsync, usa --exclude='.DS_Store' --exclude='Thumbs.db'.

Upload paralleli a chunk

Quando il servizio lo supporta, gli stream HTTP paralleli saturano la banda che una singola connessione TCP non riesce a riempire su percorsi ad alta latenza. Il protocollo tus.io supporta questo tramite upload di chunk concorrenti. Client come la libreria tus-js-client di default usano una richiesta concorrente ma possono essere configurati per usarne di più.

Per gli upload transcontinentali (ad esempio, un utente italiano verso un servizio europeo o americano), il parallelismo raddoppia o triplica il throughput effettivo. Per gli upload locali, un singolo stream di solito satura la banda di upload e il parallelismo non aggiunge nulla.

Regolazione della dimensione dei chunk

Chunk grandi riducono l'overhead per richiesta; chunk piccoli si recuperano più velocemente dai fallimenti di rete. Il compromesso dipende dalla connessione:

| Tipo di connessione | Dimensione chunk suggerita | |---|---| | Fibra gigabit, cablata | 32-64 MB | | Fibra residenziale, Wi-Fi | 10-20 MB | | Banda larga ufficio | 10 MB | | Mobile 4G/5G | 2-5 MB | | Wi-Fi instabile/hotel | 1-2 MB |

La maggior parte dei servizi consumer sceglie un valore predefinito sensato (5-10 MB) e non espone l'impostazione. Gli strumenti da riga di comando (rclone, aws s3 cp, gsutil) consentono una regolazione precisa.

La struttura delle cartelle conta meno del volume totale

Un mito comune: "le cartelle molto annidate rallentano gli upload." Non è così. Il formato archivio appiattisce i percorsi in header stringa indipendentemente dalla profondità. Una cartella di 10.000 file 3 livelli in profondità si carica in modo identico a una cartella di 10.000 file 10 livelli in profondità una volta archiviata.

Ciò che conta davvero: il numero di file individuali. 10.000 file piccoli in piano è lo stesso problema di 10.000 file piccoli annidati — archiviali.

Strategia di compressione per tipo di contenuto

• Foto miste (.jpg/.heic): .zip in modalità store. Nessuno spreco di CPU.
• Foto RAW (.cr3/.arw/.nef): .zip in modalità store. Già compressi internamente.
• Progetti video (.mp4, .mov, .prproj): .zip in modalità store.
• Codice sorgente: 7z con LZMA2 per il rapporto massimo.
• File di log: 7z con LZMA2; aspettati riduzioni da 10 a 20x.
• PDF: modalità store. La maggior parte dei PDF ha compressione interna.
• Documenti Office (.docx, .xlsx): modalità store. Sono già XML compresso in ZIP internamente.
• Dump di database (.sql): 7z con LZMA2. Eccellente compressione.

In background o in primo piano

Gli upload via browser devono tenere il tab aperto. Chiudere il tab di solito interrompe l'upload. Alcuni servizi offrono upload in background tramite Service Worker che continuano brevemente dopo la chiusura del tab, ma questo è inaffidabile su browser mobile e in alcuni profili browser aziendali.

Per upload batch davvero grandi (oltre 100 GB), i client desktop vincono perché girano come processi a livello di sistema operativo. rclone monta e sincronizza su qualsiasi cloud principale. Il client desktop di Dropbox mette in coda gli upload in modo affidabile. Questi sopravvivono alla chiusura del coperchio del laptop e ai cambi di Wi-Fi in modi che i browser faticano a gestire.

Per upload batch sotto i 10 GB, un servizio moderno basato su browser con upload a chunk via tus.io gestisce il carico di lavoro senza problemi. La cifratura lato client di HexaTransfer aggiunge un modesto overhead CPU ma non incide materialmente sul throughput sull'hardware attuale.

Dividi i batch troppo grandi

Quando il tuo batch supera il tetto per trasferimento del servizio, dividi logicamente invece che meccanicamente. Le cartelle "Foto per data" per un servizio fotografico di un mese funzionano meglio dei tagli arbitrari per dimensione in byte perché i destinatari possono verificare che ogni batch sia completo ("1-7 marzo.zip", "8-14 marzo.zip") invece di chiedersi se manca il volume .005.

Per i servizi senza limiti per trasferimento ma con limiti di sessione, gli upload sequenziali di più archivi evitano di raggiungere i cap di upload concorrenti.

Verifica prima di andartene

Gli upload batch grandi sono tentanti da avviare e dimenticare. Non farlo. Prima di chiudere il laptop:

• Conferma che la pagina di upload mostri "completato" e non "in corso"
• Apri il link in un browser diverso o in finestra in incognito e verifica l'esperienza del destinatario
• Controlla che l'archivio si apra correttamente (un .zip corrotto durante l'upload è raro ma possibile)
• Conferma che le impostazioni di scadenza corrispondano a quanto voluto

Cinque minuti di verifica valgono più di un'email imbarazzante il giorno dopo che chiede se il destinatario ha ricevuto i file.

Delta sync per batch ripetuti

Se stai aggiornando un batch — ad esempio, backup settimanali di una cartella di progetto — il re-upload completo è uno spreco. Strumenti come rclone, rsync su SSH o client di sincronizzazione dedicati trasferiscono solo i file modificati. Questo richiede archiviazione persistente (non servizi di trasferimento effimeri), quindi è un pattern di cloud storage più che di trasferimento.

Per i flussi di trasferimento veri in cui il destinatario è diverso ogni volta, l'archivio completo di ogni batch è l'approccio corretto.

In sintesi

Il percorso veloce per gli upload di cartelle: archivia tutto in un unico .zip (modalità store per contenuti pre-compressi, compressione reale per testo), salta i file di sistema inutili, deduplicali dove vale la pena, e carica il singolo archivio tramite un servizio che supporta upload riprendibili a chunk. Per batch molto grandi, usa un client desktop. La differenza tra "carica cartella direttamente" naive e il percorso ottimizzato è spesso 10x nel tempo trascorso.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.