Сначала о терминологии, потому что от неё зависят все числа ниже. В документации Microsoft лимит синхронизации считается в элементах — это файлы и папки вместе. В нашей тестовой библиотеке было 997 392 элемента, из которых 890 191 — файлы, а остальные 107 201 — папки. Когда дальше в тексте звучит «миллион файлов», речь именно об элементах в понимании Microsoft.
Короткий ответ
- 997 392элемента в тестовой библиотеке SharePoint
- 52 минпервичная синхронизация с нуля
- 351/ссредняя скорость, пик — 590 элементов/с
- 3,6 ГБпиковое потребление RAM
- 20,6 ГБпиковая потребность в месте на диске
- 5,9%загрузка канала 99 Мбит/с
- 238 минсамая долгая проверка изменений после повторного входа
- 44 из 45попыток открыть файл в этой фазе — тайм-аут
Вопрос уже не в том, может ли OneDrive синхронизировать миллион элементов. Может. Вопрос — насколько удобно работать с такой библиотекой после синхронизации.
Первичная синхронизация оказалась быстрее, чем мы ожидали, и ничего в системе не «легло»: процессор был занят на 2,1 ядра из 16, сеть — на 5,9% канала, у диска ни разу не было очереди. Проблема началась после того, как мы вышли из сеанса Windows и зашли снова — то есть сделали то, что делает любой пользователь каждое утро.
Каждое утверждение в статье помечено по типу:
Microsoft заявила — подтверждено официальной документацией.
Мы измерили — число из логов скрипта, есть сырые CSV.
Мы наблюдали — что произошло, без объяснения причины.
Наша интерпретация — наш вывод, а не факт.
Раскрытие: мы разрабатываем OneMount — инструмент, который подключает библиотеки SharePoint как диск Windows без синхронизации, поэтому у нас очевидный конфликт интересов. Именно поэтому сначала идут числа и методика, а о продукте — только после выводов. Опубликованного независимого benchmark именно такой конфигурации на миллионе реальных элементов мы не нашли; если он существует — пришлите, сравним методологию.
Действительно ли OneDrive поддерживает 1 000 000 файлов?
Да. Microsoft заявила: клиент синхронизации OneDrive в публичном превью поддерживает до 1 000 000 элементов на один экземпляр синхронизации на устройстве (документация Microsoft). Microsoft постепенно включает эту функцию для участников программы Insider.
Лимит OneDrive — 300 000 или 1 000 000 элементов?
Это самый частый источник путаницы. Microsoft заявила: 300 000 элементов остаются рекомендацией для оптимальной производительности. Замены одного числа другим не было — оба действуют одновременно и означают разные вещи.
| Количество | Что это означает |
|---|---|
| до 300 000 элементов | Рекомендация Microsoft для оптимальной производительности. Ориентир для планирования. |
| до 1 000 000 элементов | Верхняя граница поддержки в публичном превью, а не гарантия производительности. |
Требования к Windows и железу
Microsoft заявила — требования для превью на 1 000 000 элементов:
- Windows 11 или Windows Server 2022 и новее;
- минимум 16 ГБ RAM, рекомендуется 32 ГБ;
- SSD, не HDD;
- процессор уровня Intel Core i5 / AMD Ryzen 5 или лучше;
- клиент OneDrive с включённой опцией предварительных сборок;
- VDI не поддерживается.
Последний пункт стоит отдельного внимания: если инфраструктура построена на виртуальных рабочих столах, лимит 1 000 000 вас пока не касается. Поэтому наш тест и выполнялся на физической машине.
Как мы тестировали OneDrive с 1 миллионом файлов
Тестовая библиотека SharePoint
Библиотека реальная и рабочая, не сгенерированная: документы, экспорты, сканы и проектные папки за много лет, с типичными для такого корпуса длинными названиями и глубокой вложенностью.
Мы измерили: точное количество элементов мы взяли из REST API библиотеки до начала синхронизации — 997 392. Размер расходится в двух источниках, и это нормально: центр администрирования показывает 1,38 ТБ (всё хранилище сайта вместе с историей версий и корзиной), а база движка синхронизации насчитала 995 ГБ логического объёма — текущие версии файлов, то есть то, что реально синхронизируется.
Тестовая машина
| Процессор | Intel Core i9-11900K, 8 ядер / 16 потоков |
|---|---|
| Память | 32 ГБ — верхняя рекомендация Microsoft |
| Диск | NVMe SSD под профилем пользователя |
| ОС | Windows 11 Pro 25H2, сборка 26200.9457 |
| OneDrive | 26.168.0830.0004, предварительные сборки включены |
| Канал | Заявлено 99/100 Мбит/с; измерение перед забегом — 98,57 / 99,63 Мбит/с, пинг 2 мс |
| Профиль | Чистая, отдельная учётная запись Windows |
Более слабые конфигурации мы не измеряли, поэтому все числа ниже относятся только к этому стенду. Ожидание, что на машине с меньшей памятью и медленным диском будет хуже, — предположение, а не измерение.
Методика измерения
Обходить дерево файлов во время синхронизации нельзя: сам обход вмешивается в состояние файлов
и исказил бы то, что вы измеряете. Поэтому мы его не делали. Прогресс читается прямо из базы
движка синхронизации OneDrive (SyncEngineDatabase.db, SQLite) — вживую и только на
чтение. Оттуда берутся количество элементов, распределение «только в облаке / загружено
локально», секунды троттлинга со стороны сервиса и коды ответов. Нагрузка снимается через CIM,
где имена свойств не зависят от языка ОС.
Отдельно работает проба гидратации: скрипт периодически пытается открыть небольшой облачный файл из библиотеки с жёстким тайм-аутом, фиксирует результат и длительность, после чего возвращает файл в облачное состояние. Именно эта проба дала самые интересные данные.
Наша интерпретация: мы исходим из того, что записи в этой базе и формируют величину, к которой применяется лимит, — но методику подсчёта Microsoft не публикует, так что это предположение.
Сколько времени занимает синхронизация 1 000 000 файлов
52 минуты и 1 013 795 элементов
Время считается от старта замера, когда библиотека ещё не была подключена. Кнопку Sync нажали через 5 минут, счётчик элементов начал расти ещё через 25 секунд. Миллионную отметку прошли на 51,8 минуте, а рост счётчика прекратился на 52,9.
900,000 items at 46.3 min и
1,000,000 items at 51.7 min, счётчик показывает 1 013 795 элементов. В трее —
Backed up and synced.
| Элементов на устройстве | 1 013 795 (905 313 файлов + 108 482 папки) |
|---|---|
| Добавлено за этот забег | 997 379 — это и есть библиотека SharePoint |
| Было до старта | 16 418 — личный OneDrive той же учётной записи |
| Только в облаке | 905 310 из 905 313 файлов (99,9997%) |
| Загружено локально | 3 файла |
Клиент сделал ровно то, что обещал: построил полное дерево из почти миллиона элементов, не загружая содержимое. На диске появились placeholder-ы, а не файлы. Разница между 997 379 добавленными и 997 392 справочными — 13 элементов, и это расчёт на живой библиотеке, а не список найденных файлов.
Скорость синхронизации
| Отметка | Мин от старта | Скорость на отрезке |
|---|---|---|
| 100 000 | 8,8 | — |
| 300 000 | 16,5 | 402 элем./с |
| 500 000 | 23,1 | 469 элем./с |
| 700 000 | 34,2 | 297 элем./с |
| 900 000 | 46,3 | 296 элем./с |
| 1 000 000 | 51,8 | 297 элем./с |
Мы измерили: на первых двух отрезках клиент держал 402 и 469 элем./с, дальше скорость опустилась до 297 элем./с и осталась там до конца: 297,1, затем 296,5, затем 297,4. Это не постепенная деградация, а переход на ровное плато примерно на середине библиотеки. Среднее по активной фазе — 351 элем./с, пик — 590.
Наша интерпретация: причину назвать не можем. Троттлинга со стороны сервиса не было вообще — ноль окон, ноль секунд, 1 156 вызовов и ноль ошибок. Сеть, диск и процессор во второй половине были загружены не больше, чем в первой. Ровность плато скорее указывает на какой-то постоянный предел — размер пакета запроса или число параллельных потоков, — чем на накапливаемую стоимость.
Сколько RAM, CPU и диска использует OneDrive
| Ресурс | Измерено |
|---|---|
| RAM, пик | 3 579 МБ |
| RAM после завершения | 2 790 МБ |
| CPU, среднее за активную фазу | 2,1 ядра из 16 (13,1%) |
| CPU, пик | 2,35 ядра (14,7%) |
| Трафик, загружено | около 2 ГБ |
| Диск, прочитано / записано | 69,3 ГБ / 79,3 ГБ |
| Очередь к диску, 95-й перцентиль | 1 (пик 4) |
| База движка синхронизации | 2 036 МБ финально, 2 318 МБ в пике |
| Занято на диске, итого | 6,57 ГБ |
| Пиковая потребность в месте | 20,62 ГБ |
| Троттлинг сервиса | 0 окон, 0 секунд |
База на 2 ГБ. Мы измерили: движок тратит около 2,1 КБ служебной базы на каждый элемент. Эта база лежит в профиле пользователя и читается и пишется при каждой проверке изменений.
149 ГБ дисковых операций на 2 ГБ трафика. Наша интерпретация: это примерно 75-кратное усиление записи относительно объёма, полученного из сети. На NVMe незаметно; на SATA SSD начального уровня или на HDD это совсем другая история — и именно поэтому Microsoft ставит SSD в требования.
20,62 ГБ пика против 6,57 ГБ итога. Мы измерили: свободное место падало с 253,93 ГБ до 233,31 ГБ на 51,6-й минуте. Временная потребность в месте была в 3,1 раза больше того, что осталось по завершении. Практическое следствие: машина, на которой свободно около 10 ГБ, упадёт посреди синхронизации, хотя конечное состояние поместилось бы без проблем.
Нужен ли быстрый интернет для OneDrive
Мы запускали тест на канале 99 Мбит/с именно чтобы ответить на этот вопрос. Мы измерили:
| Средняя скорость загрузки | 5,87 Мбит/с — 5,9% канала |
|---|---|
| 95-й перцентиль | 12,34 Мбит/с — 12,5% канала |
| Сэмплов с загрузкой канала ≥ 80% | 0 |
| Сэмплов активной фазы с трафиком < 0,1 Мбит/с | 45,1% |
| Чистое время передачи всего трафика | около 3 минут |
Почти половину активной фазы сеть фактически молчала, а весь загруженный трафик на этом канале передаётся за неполных три минуты — при забеге в 52.
В нашем тесте канал не был узким местом. Более быстрый интернет не сократил бы этот забег.
Наша интерпретация: узкое место — не пропускная способность, а задержка служебных обращений к сервису и обработка метаданных. Миллион элементов означает миллион записей, которые нужно получить, разобрать и положить в собственную базу; более широкий канал не уменьшает количество этих операций.
Для планирования это значит: если у вас уже есть стабильные 100 Мбит/с, апгрейд канала ради более быстрой синхронизации не окупится — эти деньги лучше вложить в RAM и NVMe. Ниже 100 Мбит/с мы не измеряли.
Что происходит после синхронизации
238 минут «Looking for changes»
После завершения синхронизации мы вышли из сеанса Windows и зашли снова. Никаких изменений в библиотеке, никакой перезагрузки.
Мы измерили: процесс OneDrive стартовал в 18:18:03, а состояние «Backed up and synced» появилось в 22:15:39.
14 255 секунд = 237,6 минуты = 3 часа 58 минут — столько клиент проверял изменения в библиотеке, в которой ничего не изменилось. Это в 4,6 раза дольше самой синхронизации.
Важно сразу: эти 238 минут не повторились. Три следующих цикла входа на той же машине с той же библиотекой длились 20,7–36,6 секунды, и все пробы открытия файлов в них были успешны — подробности в разделе о повторных циклах ниже.
Детальные замеры нагрузки охватывают 116,9 минуты из 237,6 — скрипт наблюдения был запущен не с первой секунды. Полная длительность считается от старта процесса OneDrive до появления статуса; обе точки зафиксированы надёжно.
| Вызовов к сервису | 14 — из них 2 EnumChanges; ошибок 0 |
|---|---|
| Загружено из сети | около 22 МБ (верхняя граница по всей машине) |
| Диск, процесс OneDrive | 0,50 ГБ прочитано / 0,17 ГБ записано |
| База движка | не изменилась |
| Прирост элементов | ноль — ни одной записи |
| CPU | 1,03 ядра в среднем, пик 1,79 |
| RAM | выросла с 936 МБ до 2 501 МБ |
Мы измерили: счётчик элементов не изменился ни разу за всю наблюдаемую фазу — 1 013 795 на каждом сэмпле. Два новых элемента появились через 33 секунды после статуса «Backed up and synced». Из 19 обращений EnumChanges на саму фазу пришлись лишь 2, остальные 17 — на четверть часа после её завершения.
Наша интерпретация: это не похоже на загрузку данных и даже не на активный диалог с сервисом, а скорее на долгую внутреннюю работу с собственным состоянием — с той же базой на 2 ГБ. Подтвердить не можем: Microsoft не публикует, что именно клиент делает в этой фазе.
Мы наблюдали: снаружи фаза выглядит нормально. Иконка в трее показывает «Looking for changes» — то же самое, что при пятисекундной проверке после обычного утреннего включения. Мы не увидели ни индикатора прогресса, ни оценки времени, ни предупреждения. В штатном интерфейсе клиента мы не нашли признака, который отличал бы «подожди 20 секунд» от «подожди 4 часа».
Файлы не открываются во время проверки
Это уже не наблюдение на глаз, а измерение: проба гидратации работала постоянно.
| Когда | Попыток | Неудачных | Доля |
|---|---|---|---|
| Во время проверки изменений | 45 | 44 | 98% |
| После выхода в рабочее состояние | 9 | 0 | 0% |
Мы измерили: из 45 попыток открыть файл во время фазы удалась одна, и заняла она 49 342 мс — почти 50 секунд на файл размером в сотни килобайт. После выхода клиента в рабочее состояние те же пробы занимали 305–645 мс.
Ошибка 0x800701AA
Здесь нужна точность. Автоматическая проба обрывает попытку на 60-й секунде и записывает
timeout, то есть прекращает вызов раньше, чем Windows успевает вернуть код ошибки.
Мы наблюдали: код появился при ручном открытии файла в начале
той же фазы:
0x800701AA — The cloud operation was not completed before the time-out period
expired.
Мы наблюдали: Excel дважды отреагировал на эту ситуацию сообщением «file format or file extension is not valid» — приложение получило частичный или пустой поток и сделало из этого собственный ошибочный вывод. Наша интерпретация: именно так возникают конфликтные копии и «испорченные» документы: пользователь видит ошибку формата, пересохраняет файл под другим именем — и дальше цепочка разворачивается уже без участия OneDrive.
Повторяется ли это после каждой перезагрузки?
Делать из 238 минут правило было бы нечестно. Мы провели третий тест — циклы перезагрузки и входа в сеанс на той же машине с той же библиотекой. Записалось четыре прогона, три из них захватили полный цикл.
| Цикл | Триггер | До «Backed up and synced» |
|---|---|---|
| 1 | Чистая перезагрузка | 36,6 с (129,6 с от загрузки системы) |
| 2 | Вход в сеанс, машина работала 11 часов | 20,7 с |
| 3 | Вход в сеанс, 74 минуты после старта | 35,8 с |
Мы измерили: разброс на одинаковой основе — 20,7–36,6 секунды. Проба гидратации за эти циклы выполнилась 12 раз из 12 успешно, причём шесть проб пришлись именно на состояние «Looking for changes» — все успешные, 707–2 572 мс. В установившемся состоянии процесс держал 1 507–2 187 МБ памяти: на миллионной библиотеке полтора-два гигабайта RAM заняты постоянно.
[11:20:31] state -> LookingForChanges и три пробы подряд успешны
(2 212, 707 и 1 062 мс). То же название состояния, что и во время 238-минутной фазы, но
поведение противоположное.
Оговорка: мы не можем утверждать, что в этих циклах клиент выполнял тот же объём работы. Долгая фаза была первым входом после первичной синхронизации, три следующих — нет. Частоту мы не измеряли.
Наша интерпретация: именно в этом и состоит эксплуатационная проблема. Событие, которое происходит редко и непредсказуемо, но длится часами и выглядит как норма, управляется хуже, чем явная ошибка: ошибку видно в мониторинге, а это состояние — нет.
Что значит миллион файлов для сотен ПК
Наша интерпретация: всё в этом разделе — выводы из опыта внедрения, а не измеренные числа.
Ресурсы умножаются на количество машин. 6,6 ГБ на диске в установившемся состоянии и до 21 ГБ в пике — на каждом устройстве. 2 ГБ служебной базы, которую нужно читать и писать при каждой проверке изменений. 3,6 ГБ RAM в пике: на машинах с 8 ГБ это уже конкуренция с рабочими приложениями, и требование Microsoft в 16 ГБ минимум — не формальность.
Редкое событие на большом парке перестаёт быть редким. Частоты патологической фазы мы не знаем и выдумывать не будем, но логика масштаба однозначна: на сотнях машин даже редкая эпизодическая проблема перестаёт быть проблемой одного пользователя — её масштаб определяется количеством устройств и частотой таких событий.
Пользователи не ждут. 52 минуты получены на идеальной машине без посторонней нагрузки; на рабочем ноутбуке каждое открытие файла и запуск Excel конкурирует с синхронизацией за те же диск и процессор.
Второе устройство — это второй такой же забег. Лимит сформулирован как «на экземпляр синхронизации на устройстве»: человек с ноутбуком и стационарным ПК проходит весь цикл дважды.
Что показал тест
Работает лучше, чем ожидалось. Первичная синхронизация миллиона элементов быстрая, предсказуемая и дешёвая по ресурсам: 52 минуты, 2 ГБ трафика, 2 ядра из 16, ноль ошибок сервиса, ноль троттлинга. Инженерно это серьёзный результат.
Что оказалось проблемой в нашем тесте. После первичной синхронизации клиент провёл 238 минут в состоянии «Looking for changes», и 44 из 45 попыток открыть файл завершились тайм-аутом. Три следующих цикла входа это поведение не воспроизвели.
Практические ориентиры:
- До 300 000 элементов — синхронизация OneDrive остаётся разумным выбором, и наши данные рекомендации Microsoft не противоречат.
- От 300 000 до 1 000 000 — работать будет, но только на машинах, соответствующих требованиям превью, и с пониманием, что вы на территории «поддерживается», а не «рекомендуется».
- Парк из сотен машин — оценивайте не время первичной синхронизации, а стоимость сопровождения установившегося состояния.
- VDI — лимит 1 000 000 вас не касается.
Нужно работать с большой библиотекой SharePoint без локальной синхронизации?
OneMount подключает SharePoint и OneDrive как диск Windows: файлы остаются в облаке, а пользователь работает с ними в Проводнике — без первичной синхронизации большой библиотеки и без локального индекса миллиона элементов.
Попробовать OneMount →Как работать с большой библиотекой SharePoint
Разделить библиотеку
Разбить корпус на несколько библиотек или сайтов так, чтобы каждое устройство синхронизировало меньше 300 000 элементов. Работает, но требует перестройки структуры, переучивания людей и ломает ссылки — часто организационно дороже, чем технически.
Выборочная синхронизация
Опция «Выбрать папки» позволяет не тянуть всё дерево. Но лимит считает то, что вы выбрали, пользователи рано или поздно включают лишнее, и это не спасает от фазы проверки изменений для того, что всё-таки синхронизируется.
Работа через браузер
Самый безопасный вариант с точки зрения клиента и худший с точки зрения привычки: там, где люди годами работали с буквой диска, возврат к веб-интерфейсу встречает сопротивление, и часть команды найдёт обходные пути.
Подключить SharePoint как диск без синхронизации
Направление, в котором пошли мы — и здесь повторим раскрытие конфликта интересов: мы разрабатываем OneMount, поэтому не являемся нейтральной стороной.
Логика проста. Все числа в этой статье — 52 минуты, 2 ГБ базы, 149 ГБ дисковых операций, 238 минут проверки — это стоимость содержания локальной копии состояния миллиона элементов. Без неё нет и этой стоимости: нечего проверять после входа, нет базы, которая растёт линейно с количеством элементов, нет пика в 21 ГБ на системном диске. Взамен появляются другие компромиссы: нужно соединение, а задержка открытия документа зависит от канала, а не от локального диска.
Наша интерпретация: для библиотек, где большая часть корпуса — архив, к которому обращаются редко (в нашей тестовой за 30 дней тронули около 2% файлов), держать полный локальный индекс миллиона элементов на каждом устройстве выглядит как большая плата за малую пользу. Но это наша оценка, и ваш профиль использования может быть другим.
FAQ: OneDrive и 1 000 000 файлов
Сколько файлов может синхронизировать OneDrive?
До 1 000 000 элементов на один экземпляр синхронизации на устройстве — в публичном превью, при соответствии требованиям. Лимит считается в элементах, то есть файлы и папки вместе.
Какой лимит OneDrive — 300 000 или 1 000 000 файлов?
Оба. 300 000 — рекомендация Microsoft для оптимальной производительности, 1 000 000 — верхняя граница поддержки в публичном превью. Замены одного числа другим не было.
Сколько времени занимает синхронизация 1 миллиона файлов?
В нашем тесте — 52 минуты для 997 392 элементов на машине с Core i9, 32 ГБ RAM, NVMe SSD и каналом 99 Мбит/с. Средняя скорость активной фазы — 351 элемент/с. На более слабой машине или при параллельной нагрузке будет дольше.
Можно ли синхронизировать 1 миллион файлов OneDrive на Windows 11?
В публичном превью Microsoft поддерживает до 1 000 000 элементов на один экземпляр синхронизации при выполнении требований к Windows, RAM, SSD и клиенту OneDrive. В нашем тесте Windows 11 Pro 25H2 с 32 ГБ RAM и NVMe SSD синхронизировала 997 392 элемента примерно за 52 минуты.
Почему OneDrive зависает на «Looking for changes»?
Мы зафиксировали два режима с одинаковым названием в интерфейсе: короткий (20,7–36,6 секунды, файлы доступны) и долгий (238 минут, 44 из 45 попыток открыть файл завершились тайм-аутом). Причину перехода в долгий режим мы не установили, а признака, который бы различал эти состояния, в штатном интерфейсе нет.
Почему OneDrive медленно синхронизирует большую библиотеку?
По нашим измерениям узкое место — не сеть и не диск, а задержка служебных обращений к сервису и обработка метаданных. Показательно, что скорость держится на уровне 402–469 элементов/с только на первой половине библиотеки, а дальше падает до постоянных 297 и больше не восстанавливается.
Сколько оперативной памяти использует OneDrive?
Пик во время первичной синхронизации — 3 579 МБ. В установившемся состоянии, когда ничего не происходит, процесс держал 1 507–2 187 МБ. В фазе долгой проверки изменений потребление росло с 936 МБ до 2 501 МБ за два часа наблюдения.
Сколько места на диске занимает синхронизация миллиона элементов?
6,57 ГБ в установившемся состоянии при полностью облачных файлах, с пиком до 20,62 ГБ во время забега. Из них 2 036 МБ — служебная база движка синхронизации, примерно 2,1 КБ на элемент.
Нужен ли быстрый интернет для синхронизации OneDrive?
По нашим измерениям — нет, если у вас уже около 100 Мбит/с. OneDrive использовал в среднем 5,9% канала и ни разу не приблизился к насыщению.
Что означает ошибка OneDrive 0x800701AA?
«The cloud operation was not completed before the time-out period expired» — запрос на загрузку содержимого облачного файла не уложился в отведённое время. В нашем тесте мы увидели этот код во время долгой фазы проверки изменений; вне её ни одна попытка открыть файл не завершилась ошибкой.
Поддерживает ли OneDrive 1 миллион файлов в VDI?
Нет. Microsoft прямо указывает, что VDI не поддерживается в этом превью.
Как работать с большой библиотекой SharePoint без синхронизации?
Вариантов четыре: разделить библиотеку, синхронизировать выборочно, оставить людей в браузере или подключить библиотеку как диск Windows без локальной копии состояния. Последний вариант снимает всю стоимость, измеренную в этой статье, но требует постоянного соединения — подробнее в разделе «Как работать с большой библиотекой SharePoint».
Практическая сторона вопроса — как именно подключить SharePoint буквой диска, какие методы существуют и что из них выдерживает нагрузку: подключение SharePoint как сетевого диска в Windows →
Если вы уже проходили этот путь и узнаёте симптомы — наша история о годе борьбы с синхронизацией терабайтной библиотеки →
Источники
- Microsoft — ограничения и лимиты в OneDrive и SharePoint: рекомендация 300 000 элементов.
- Microsoft Learn — поддержка клиента синхронизации в VDI.
- Microsoft — синхронизация OneDrive застряла на «processing changes».
- Собственные замеры SkylFlow, 19–20 сентября 2026: три теста на физической машине, полный лог в CSV и JSON.
Воспроизводимость. Все числа получены собственным скриптом измерения, который читает базу движка синхронизации OneDrive вживую и только на чтение, а нагрузку снимает через CIM. Скрипт, протокол теста и сырые CSV готовим к публикации — напишите нам, если хотите повторить тест на своей библиотеке.