אותו 1 GB, ובכל זאת תיקיית תמונות מועתקת לאט יותר מסרטון אחד — למה?

סרטון של 1 GB הועתק מיד, ותיקיית תמונות שסכומה 1 GB נראית כאילו היא לא נגמרת. עברתם ל-SSD חדש, אבל מהירות ההעברה צונחת ברגע שמעבירים הרבה קבצים קטנים.

אם הגודל זהה, גם הזמן אמור להיות זהה — אבל מה שקובע את זמן ההעתקה אינו רק “כמה בתים להעביר” אלא גם “כמה קבצים לטפל בהם”.

המאמר הזה הוא מבוא למשתמשים יומיומיים שמעתיקים תמונות ומסמכים לכוננים חיצוניים או ל-NAS ב-Windows 11. הוא מסביר את המנגנון, ואז מציג נוהל להשוואת נתונים באותו גודל כולל בעצמכם. הוא מבוסס על תיעוד רשמי שנבדק ב-5 בספטמבר 2026, ואינו תוצאה של מדידת מהירות של PC או NAS מסוים.

1. “להעביר 1 GB” ו”לעבד 10,000 פריטים” הן עבודות שונות

חשבו על מעבר דירה: גם כשהמשקל הכולל זהה, ארגז גדול אחד ו-10,000 חבילות קטנות שצריך לבדוק את כתובת כל אחת מהן אינם אותה כמות עבודה. גם לקבצים יש עבודה לפני ואחרי העברת התוכן.

flowchart TB
    accTitle: אותו גודל, מספר קבצים שונה
    accDescr: גם עם 1 GB נתונים בסך הכול, קובץ אחד והרבה קבצים דורשים מספר שונה של פעולות ניהול.
    A["1 GB נתונים בסך הכול"] --> B["קובץ גדול אחד"]
    A --> C["10,000 קבצים קטנים"]
    B --> D["מעט פעולות לכל קובץ"]
    C --> E["פעולות לכל קובץ שחוזרות"]

איור 1: אותו מספר בתים אינו אומר אותו מספר קבצים.

גם Microsoft מסבירה שכשמעתיקים ברשת הרבה קבצים קטנים אחד אחרי השני, עבודה שאינה העברת נתונים משתלטת ואי אפשר לנצל את מהירות הקו במלואה.¹

כמובן, זו לא כלל לפי פורמט בסגנון “תמונות איטיות, סרטונים מהירים”. כמה תמונות גדולות ועשרות אלפי תמונות זעירות הם מצבים שונים. מתחילים בפתיחת Properties של התיקייה ומסתכלים על גם הגודל הכולל וגם מספר הקבצים. להשוואה, מתאימים את סך הבתים של תוכן הקבצים, לא את “Size on disk”.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 11, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. העתקה מטפלת ביותר מהתוכן

כשמעתיקים קובץ, פותחים את המקור, יוצרים את קובץ היעד, קוראים וכותבים את התוכן, מגדירים את המידע הנדרש, וסוגרים. פתיחת קובץ ב-Windows כוללת גם תנאים כמו הרשאות גישה והאם פעולות אחרות רשאיות לפתוח את הקובץ באותו זמן.²

המידע שמשמש לניהול קובץ, כמו שם, גודל וחותמות זמן, נקרא metadata. מערכת הקבצים NTFS, למשל, רושמת מידע ניהול לכל קובץ במבנים כמו MFT (Master File Table). זה אינו מנגנון שבו כתיבת נתוני הפיקסלים של התמונה היא כל הסיפור.³

flowchart TB
    accTitle: העבודה בהעתקת קובץ אחד
    accDescr: מלבד קריאת המקור, יצירת היעד, ניהול המידע שלו וסגירה נדרשים לכל קובץ.
    A["פותחים את המקור"] --> B["יוצרים את היעד"]
    B --> C["קוראים וכותבים את התוכן"]
    C --> D["מגדירים את המידע וסוגרים"]
    D -.-> E["חוזרים לקובץ הבא"]

איור 2: זרימה מושגית. סדר הפעולות בפועל וכל הרצה במקביל תלויים בשיטת ההעתקה ובמערכת הקבצים.

SSD לא גורם לעבודת הניהול הזו להיעלם. נתון קצב ההעברה הגדול בדף המפרט של המוצר לבדו לא אומר כמה זמן ייקח להעתיק 10,000 קבצים. גם גס מדי לקרוא להעתקת קבצים קטנים פשוט “הכול random I/O”. מעבר למקום שבו הנחיתות והכתיבות נוחתות, צריך לשקול בנפרד את עבודת הטיפול בקבצים עצמה.

3. ב-NAS מתווסף גם “להמתין לתשובה מהצד השני”

NAS הוא התקן אחסון שמשתמשים בו דרך הרשת. עם SMB (Server Message Block), הפרוטוקול מאחורי תיקיות משותפות ב-Windows, פעולות קבצים מבוקשות מהצד השני, ויש נקודות שבהן ה-PC ממתין שהצד הזה יעבד ויענה.

flowchart TB
    accTitle: פעולות קבצים דרך רשת
    accDescr: בקשת פעולה מה-PC עוברת ברשת, הופכת לפעולת קובץ בצד השני, והתשובה חוזרת ל-PC.
    A["ה-PC מבקש פעולת קובץ"] --> B["עובר ברשת"]
    B --> C["הצד השני מעבד את הקובץ"]
    C --> D["התשובה חוזרת ל-PC"]

איור 3: היכולת להעביר הרבה בבת אחת וקבלת תשובה מהירה לפעולה בודדת הן שני דברים שונים.

Bandwidth מקביל למספר הנתיבים בכביש; latency מקביל לזמן עד שחוזרת תשובה. כשההמתנה לכל קובץ קטן גדלה, הכמות שמועברת לא עולה גם כשיש רוחב פס פנוי. גם סריקת אנטי-וירוס יכולה להשפיע על זמן העיבוד לכל קובץ.¹

עם זאת, זה לא אומר שכל קובץ תמיד דורש מספר קבוע של round trips. ל-SMB יש מנגנון לאיגוד בקשות, וגם תנאי cache ומקביליות משנים איך ההמתנה מתנהגת.⁴⁵ התוצאות שונות גם בין LAN ביתי לבין תיקייה משותפת באתר מרוחק.

דוגמה מפושטת לחשיבה במספרים

בהנחה שהכול מעובד ברצף בלי חפיפה, החשיבה נראית כך.

Copy time ≈ total bytes ÷ data transfer rate
          + number of files × extra time per file

זה אינו ערך מדידה ואינו הנוסחה המדויקת של Windows. להמחשה, מניחים שחלק הנתונים רץ ב-100 MB/s והזמן הנוסף הוא 2 מילישניות לקובץ. כאן 1 GB = 1,000 MB.

חלק הנתונים של 1 GB לוקח 10 שניות. עם קובץ אחד הזמן הנוסף הוא 0.002 שניות, אבל עם 10,000 קבצים זה 20 שניות, ובסך הכול כ-30 שניות. המודל משמיט מקביליות, cache, ומגבלות CPU ואחסון, אבל הוא כן מסביר למה “אותו גודל לוקח זמן שונה”.

flowchart TB
    accTitle: פיצול זמן ההעתקה לשני חלקים
    accDescr: מבחינים בין זמן ההעברה שנקבע לפי הגודל הכולל לבין הזמן הנוסף שמצטבר עם מספר הקבצים.
    A["זמן יחסי לגודל הכולל"] --> C["זמן ההעתקה הכולל"]
    B["זמן נוסף יחסי למספר הקבצים"] --> C

איור 4: כשמספר הקבצים גדל, מתחיל להיות חשוב זמן שלא נראה מנפח הנתונים לבדו.

4. ZIP לא רק “מקטין” — הוא גם “אוגד לאחד”

ל-ZIP יש שני תפקידים: דחיסת נתונים ואיגוד כמה קבצים למיכל אחד. JPEG הוא כבר פורמט דחוס, ולכן הכנסה ל-ZIP עשויה לא להקטין את הנפח בהרבה.⁶

גם אז יש אפקט נפרד: מספר הקבצים שמטפלים בהם בהעברה יורד מ-10,000 לאחד. להסתכל רק על יחס הדחיסה ולהסיק ש”ה-ZIP היה מיותר” זה מוקדם מדי.

flowchart TB
    accTitle: שני התפקידים של ZIP
    accDescr: השינוי במספר הקבצים מאיגוד ל-ZIP והשינוי בגודל מדחיסה הם אפקטים נפרדים.
    A["אוגדים את התמונות ל-ZIP"] --> B["קובץ אחד להעברה"]
    A --> C["שינוי הגודל תלוי בתוכן"]

איור 5: גם כשכמעט שום דבר לא נדחס, מספר הקבצים להעברה יורד.

אבל גם האיגוד וגם החילוץ אינם בחינם. אם רוצים להשתמש בתמונות כתיקייה רגילה, משווים את הסכום הבא.

זמן דרך ZIP = יצירת ZIP + העברת ZIP + חילוץ

יצירת ה-ZIP קוראת את הקבצים הקטנים, והחילוץ יוצר אותם שוב ביעד. הנקודה אינה לבטל את העבודה לכל קובץ אלא לשנות איפה העבודה הזו קורה ואת צורת ההעברה. אם העיבוד לפני ואחרי ההעברה כבד, בלי איגוד יכול להיות מהיר יותר.¹

5. “איפה מחלצים” משנה מה ZIP נותן

אם שולחים את ה-ZIP ל-PC המקבל ומחלצים אותו בכונן המקומי של אותו PC, אין צורך להזרים את הקבצים הקטנים אחד-אחד ברשת. גם ההנחיה של Microsoft מציינת חילוץ הארכיון במערכת היעד כשיטה.¹

flowchart TB
    accTitle: חילוץ ביעד מול חילוץ מה-PC אל ה-share
    accDescr: מבחינים בין הנתיב שבו היעד מחלץ פנימית לבין הנתיב שבו ה-PC כותב את הקבצים שחולצו אל ה-share.
    A["שולחים את ה-ZIP ליעד"] --> B["היעד מחלץ פנימית"]
    C["אפליקציה ב-PC מחלצת"] --> D["קבצים קטנים נשלחים ל-share"]

איור 6: “ה-ZIP נמצא על ה-NAS” לבדו אינו אומר שהחילוץ מתבצע בתוך ה-NAS.

כאן קל לטעות. אם פותחים ZIP שעל ה-NAS ב-File Explorer ב-PC ובוחרים את אותה תיקייה משותפת כיעד החילוץ, ה-PC כותב את הקבצים הקטנים שחולצו אל ה-NAS, כך שפעולות הרשת הדקות קורות שוב.

מבחינים בין זה לבין המקרה שבו ל-NAS עצמו יש יכולת חילוץ נתמכת שיכולה לרוץ בתוך ה-NAS, ממסוף הניהול וכדומה. אם אין יכולת כזו, לא מסתפקים ב”שליחת ZIP פותרת”; מודדים את כל הנתיב שבאמת משתמשים בו. כשמשווים חילוץ בתוך ה-NAS לחילוץ לכונן המקומי של ה-PC, זוכרים גם שהמיקום הסופי של הקבצים שונה.

6. השוואת גדול, קטן ו-ZIP באותו 1 GB

אפשר להתחיל בניסיון עם סרטון ותמונות שכבר יש. אבל כי התוכן, מספר הקבצים ויכולת הדחיסה כולם שונים, משתמשים בנתוני ניסוי כשרוצים לבודד את הסיבה. מה שבא אינו מהירויות מדודות אלא נוהל השוואה להריץ בסביבה שלכם.

מכינים שלושה דברים: קובץ גדול אחד, 10,000 קבצים קטנים, ו-ZIP לא דחוס שאוגד את אותם 10,000 קבצים. תוכן A ו-B שניהם מסתכמים בדיוק ב-1,000,000,000 בתים. ל-C מתווסף מידע ניהול של ZIP, כך שגודל הקובץ לא יתאים בדיוק ל-A ו-B.

flowchart TB
    accTitle: שלושה סוגי נתוני השוואה
    accDescr: יוצרים קובץ גדול אחד וקבוצת קבצים קטנים באותו גודל כולל, ואז יוצרים ZIP לא דחוס מהאחרונים.
    A["מכינים אותו 1 GB כולל"] --> B["קובץ אחד של 1 GB"]
    A --> C["10,000 קבצים של 100 KB"]
    C --> D["אותו תוכן ל-ZIP לא דחוס"]

איור 7: עם ZIP לא דחוס קל יותר לצפות באפקט של איגוד הקבצים בנפרד מהבדל ביחס הדחיסה.

יצירת קבצי הניסוי (רשות)

זה לקוראים שיכולים להשתמש בשורת הפקודה. ב-Windows PowerShell 5.1 ואילך, יוצרים תיקיית ניסוי חדשה בתיקייה הזמנית המקומית. הקובץ הגדול והקבצים הקטנים לבדם תופסים כ-2 GB, כ-3 GB כולל ה-ZIP, וגם ליעד צריך מקום פנוי משלו. כדי לא למלא את הדיסק, מוודאים שלמקור יש לפחות כ-5 GB פנויים.

לא משתמשים בתמונות או במסמכים קיימים. הנתונים נוצרים ממספרים פסבדו-אקראיים, כך שאי אפשר לפתוח את הקבצים כסרטונים או כתמונות. זה נמנע מדחיסה קיצונית שהייתה מתקבלת מנתונים מלאים באפסים בלבד, אבל אינו משחזר סריקה או התנהגות אפליקציה לתמונות אמיתיות.

$ErrorActionPreference = 'Stop'
$lab = Join-Path ([System.IO.Path]::GetTempPath()) ('copylab-' + [guid]::NewGuid().ToString('N'))
$drive = New-Object System.IO.DriveInfo ([System.IO.Path]::GetPathRoot($lab))
if ($drive.AvailableFreeSpace -lt 5GB) {
    throw 'ודאו שלכונן הניסוי יש לפחות 5 GB פנויים.'
}
$largeDir = Join-Path $lab 'large'
$smallDir = Join-Path $lab 'small'
[System.IO.Directory]::CreateDirectory($largeDir) | Out-Null
[System.IO.Directory]::CreateDirectory($smallDir) | Out-Null
Write-Host "נוצר ב: $lab"

$fileCount = 10000
$buffer = New-Object byte[] 100000
$random = New-Object System.Random 20260905
$large = [System.IO.File]::Open(
    (Join-Path $largeDir 'one.bin'),
    [System.IO.FileMode]::CreateNew,
    [System.IO.FileAccess]::Write,
    [System.IO.FileShare]::None
)
try {
    for ($i = 0; $i -lt $fileCount; $i++) {
        $random.NextBytes($buffer)
        $name = 'part-{0:D5}.bin' -f $i
        [System.IO.File]::WriteAllBytes((Join-Path $smallDir $name), $buffer)
        $large.Write($buffer, 0, $buffer.Length)
    }
}
finally {
    $large.Dispose()
}
Write-Host "ההכנה הושלמה. תוכן כל קבוצת נתונים הוא $([long]$fileCount * $buffer.Length) בתים."

אותו רצף בתים נכתב גם לחתיכות הקטנות וגם לקובץ הבודד. אחר כך, באותו חלון PowerShell, יוצרים את ה-ZIP הלא דחוס. רושמים כאן את זמן היצירה. NoCompression מאחסן את הקבצים ב-ZIP בלי לדחוס אותם.⁷

$zip = Join-Path $lab 'small.zip'
$watch = [System.Diagnostics.Stopwatch]::StartNew()
Compress-Archive -LiteralPath $smallDir -DestinationPath $zip -CompressionLevel NoCompression
$watch.Stop()
Write-Host "יצירת ZIP: $($watch.Elapsed.TotalSeconds) שניות"
Write-Host "גודל ZIP: $((Get-Item -LiteralPath $zip).Length) בתים"

הנוהל הזה מיועד רק לקבצים הרגילים שנוצרו. ל-Compress-Archive יש מגבלות כמו התעלמות מקבצים מוסתרים, לכן לא ממחזרים אותו כפי שהוא לגיבוי מלא של תיקייה חשובה.⁷ אם הוא נעצר בשגיאה, לא משתמשים באותה הרצה למדידה; בודקים את תיקיית הניסוי שהנתיב שלה הוצג. מנקים רק אחרי שמוודאים שזו התיקייה שיצרתם בעצמכם.

שמירה על תנאי המדידה זהים

משתמשים באותם התקני מקור ויעד, אותה רשת, ואותה שיטת העתקה. בהתחלה מעתיקים את שלושתם ב-File Explorer; לא משתמשים בהעברה. היעד הוא תיקייה חדשה וריקה בכל פעם, כדי שדילוג על קבצים קיימים או בקשות overwrite לא יתערבבו.

flowchart TB
    accTitle: נוהל לשמירה על תנאי השוואה זהים
    accDescr: מקבעים את נתיב ההעתקה ואת השיטה, מעתיקים ליעד ריק כמה פעמים בסדר משתנה, ובודקים את התוכן אחרי הסיום.
    A["אותם התקנים, נתיב ושיטה"] --> B["יעד ריק בכל פעם"]
    B --> C["מודדים כמה פעמים בסדר משתנה"]
    C --> D["בודקים גם מספר ותוכן"]

איור 8: לא מתייחסים לזמן שנחסך מדילוג על קבצים שכבר הועתקו כהעברה מהירה יותר.

מודדים כל מקרה, למשל, שלוש פעמים, משנים את הסדר, ורושמים את החציון ואת הפיזור. Windows שומר קבצים ב-cache בזיכרון, כך שרק ההרצה השנייה עלולה לצאת מהירה יותר. יעד חדש אינו מנקה את ה-cache בצד הקריאה. מה שהנוהל הזה חושף הוא מגמה קרובה להעתקה יומיומית, לא ביצועי מדיה קפדניים בלי cache.⁵

העתקות בתוך אותו כונן פיזי מתחרות זו בזו בקריאה ובכתיבה, לכן לא מערבבים אותן עם העתקות להתקן נפרד. לא משתמשים בקבצי ענן online-only, כי זמן המשיכה ייכלל, ולא משנים תנאים כמו אנטי-וירוס או סנכרון באמצע.

זו טבלה לרישום; אין בה מספרי תוצאה. A הוא ביקורת לצפייה במאפייני ההעברה; כי מבנה הקבצים שונה, הוא אינו תחליף ל-B. להשוואה המעשית בין B ל-C, המטרה היא להניח את אותה קבוצת קבצים באותו מיקום סופי. תמיד רושמים גם איפה בוצע החילוץ.

אחרי העתקה או חילוץ, משווים את מספר הקבצים ואת סך הבתים, ובודקים את התוכן ב-hashes אם צריך. קריאות האימות נעשות מחוץ למדידה, ומציינים שהן גם משפיעות על ה-cache לניסוי הבא. הזמן עד שחלון ההעתקה נסגר אינו מודד את הזמן עד שהנתונים יכולים לשרוד ניתוק חשמל, לכן גם לא עושים ניסוי של ניתוק התקן חיצוני מיד אחר כך.⁵

7. כשאי אפשר להשתמש ב-ZIP, מעתיקים במקביל קצת בכל פעם

לשימושים שבהם קבצים בודדים חייבים להיות זמינים ביעד מיד, או שבהם שולחים בכל פעם רק את הקבצים שהשתנו, איגוד ל-ZIP עלול לא להתאים. ל-robocopy המובנה ב-Windows יש /MT, שמטפל בכמה קבצים במקביל.⁸⁹

flowchart TB
    accTitle: חפיפת ההמתנה לכל קובץ במקביל
    accDescr: בעבודה על כמה קבצים בבת אחת, העברה אחרת יכולה להתקדם בזמן שקובץ אחד ממתין.
    A["מטפלים בכמה קבצים בבת אחת"] --> B["קובץ A ממתין לתשובה"]
    A --> C["קובץ B בהעברה"]
    B --> D["ההמתנות חופפות"]
    C --> D

איור 9: מקביליות היא דרך לחפוף המתנות; היא לא מאיצה את הקו או את הדיסק עצמם.

הדוגמה הבאה מעתיקה מ-$smallDir שנוצר קודם. משנים רק את $targetRoot ליעד שאפשר לכתוב אליו. יוצרים תיקיית יעד נפרדת לכל הרצה, ולא משתמשים באפשרויות שמוחקות את נתוני המקור או את היעד.

$targetRoot = '\\NAS\share\CopyLab' # שנו ליעד שלכם
$runId = [guid]::NewGuid().ToString('N')
$target = Join-Path $targetRoot ('small-mt8-' + $runId)
$log = Join-Path $lab ('robocopy-' + $runId + '.log')
robocopy $smallDir $target /E /MT:8 /R:1 /W:1 /XJ "/LOG:$log"
$code = $LASTEXITCODE
if ($code -ge 8) {
    throw "בהעתקה היו כשלים. קוד יציאה=$code, לוג=$log"
}
Write-Host "קוד יציאה=$code. בדקו ב-לוג את מספר המועתקים ומספר הכשלים ואת תוכן היעד: $log"

/MT:8 פירושו 8 threads, /R:1 /W:1 הם מספר הניסיונות החוזרים וההמתנה בשניות בכשל, ו-/LOG שומר את הלוג. robocopy מדווח על העתקה מוצלחת גם עם exit code 1, ו-8 ומעלה כוללים כשלים. זה לא אומר ש-0 עד 7 פוטרים מבדיקת התוכן.⁸

/MT:8 הוא דוגמת נקודת התחלה להשוואה, לא ערך אופטימלי. יותר מדי מקביליות מגדילה את העומס בצד השני ויכולה אפילו להאט.¹ מגבילים מה משנים בכל פעם, למשל בהשוואת /MT:1 ו-/MT:8 באותה שיטה. לא שופטים את האפקט של אחד מהם מתוצאה שבה שינו את ה-ZIP ואת המקביליות באותו זמן.

8. לפני שמסיקים “זה איטי, אז זה שבור”

האם רק הרבה הקבצים הקטנים איטיים, או שגם קבצים גדולים איטיים? מה קורה כשאותם קבצים מועתקים מקומית? הפרדה של אלה מצמצמת איפה לבדוק. כשהמהירות יורדת באמצע, ייתכן שה-cache מעורב, והמהירות המוצגת לבדה אינה מאתרת את הסיבה.⁵

flowchart TB
    accTitle: בידוד העתקות איטיות
    accDescr: חוקרים איטיות שמוגבלת לקבצים קטנים בנפרד מאיטיות בלי קשר לסוג הנתונים.
    A{"רק קבצים קטנים איטיים?"} -->|"כן"| B["מסתכלים על מספר קבצים וזמן המתנה"]
    A -->|"לא"| C["בודקים גם התקן, חיבור ועומס"]
    B --> D["בודקים גם כשלים או ניתוקים"]
    C --> D

איור 10: מהירות שלא מתרחבת עם קבצים קטנים וכשלי העתקה או תקלות התקן אינם אותו סיפור.

כשמופיעים כשלי העתקה או ניתוקים, או שהמצב הורע פתאום בהרבה לעומת קודם, לא עוצרים בהסבר לפי מספר קבצים בלבד. שמים את שמירת הנתונים החשובים ראשונה, ובודקים לוגים ואת מצב ההתקנים.

גם עצירת אנטי-וירוס או כיבוי SMB signing כדי להרוויח מהירות אינם מומלצים. SMB signing משמש בין השאר למניעת שיבוש בתקשורת.¹⁰ במחשב מנוהל לא עוקפים את ההגדרות; מתייעצים עם האחראי.

סיכום

זמן ההעתקה מורכב גם מזמן יחסי לכמות הנתונים וגם מעבודה יחסית למספר הקבצים. לכן “זה 1 GB, אז זה לוקח אותו זמן” לא בהכרח מחזיק.

אם מנסים ZIP, מסתכלים מעבר ליחס הדחיסה גם על יצירה, העברה וחילוץ. אם מנסים העתקה במקביל, משנים בכל פעם רק את מספר ה-threads. לפני שקונים חומרה מהירה יותר, הסתכלות על הגודל הכולל ועל מספר הקבצים יחד מקלה להסביר מה קורה ב-Windows שלכם עכשיו.

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

למה תיקיית תמונות מועתקת לאט יותר גם כשהגודל זהה?

העתקה אינה רק העברת תוכן. לכל קובץ נוצרים קובץ היעד, מנוהל המידע שלו, הוא נסגר, וכן הלאה. כשיש הרבה קבצים קטנים, חלק העיבוד וההמתנה הזה גדל. מה שחשוב אינו פורמט התמונה עצמו אלא מספר הקבצים וגודל כל אחד.

גם ב-SSD או ב-LAN מהיר קבצים קטנים מועתקים לאט?

כן. גם ב-SSD עבודת ניהול הקבצים נשארת, ובהעתקה ל-NAS וכדומה מתווסף הזמן שמחכים לרשת ולעיבוד בצד השני. מהירות העברה רציפה של קבצים גדולים ומהירות הטיפול בהרבה קבצים קטנים הן שני דברים שונים.

אם JPEG כמעט לא קטן ב-ZIP, יש טעם לאגד אותם?

גם כשהנפח כמעט לא יורד, איגוד הקבצים להעברה לאחד עדיין משפיע. יצירת ה-ZIP והחילוץ גם לוקחים זמן. לשימושים שדורשים חילוץ, משווים את הזמן הכולל של יצירה, העברה וחילוץ.

מהיר יותר לשלוח ZIP ל-NAS ואז לחלץ אותו לתיקייה המשותפת מה-PC?

בשיטה הזו ה-PC כותב את הקבצים הקטנים שחולצו אל ה-NAS, כך שיצירת קבצים דרך הרשת קורה שוב. מבחינים בין זה לבין חילוץ בתוך ה-NAS עם יכולת שה-NAS עצמו תומך בה, ומודדים כולל החילוץ.

העתקה במקביל של robocopy נהיית מהירה יותר ככל שמוסיפים threads?

לא. מקביליות מאפשרת להמתנות לכל קובץ לחפוף, אבל גם מגדילה את העומס על האחסון או על ה-NAS. משווים באותם תנאים החל ממספר threads קטן, ובודקים בלוג גם כשלי העתקה וקבצים שהוחמצו.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.