Высокопроизводительные потоки управления файлами и завершения ввода / вывода - PullRequest
2 голосов
/ 29 сентября 2010

Два вопроса о производительности файлов:

Мне нужно создать сервер, который потенциально обрабатывает тысячи одновременных запросов:

  • Хеширование файлов
  • Сжатиеfiles
  • Распаковка файлов
  • Возможно, копирование / перемещение некоторых файлов также

Я не могу контролировать аппаратное обеспечение клиента (конфигурации RAID и т. д.), поэтому я предполагаювсе, что я могу сделать, это запросить сотни файловых операций и позволить ОС и контроллеру диска обеспечить любую возможную оптимизацию.Правильно?

Следующий вопрос: я бы хотел максимально использовать потоки завершения ввода-вывода (вместо рабочих потоков).Единственные, которые я считаю доступными для меня, через .net 3.5 в любом случае, предлагаются через "BeginRead / Write" в:

  • System.IO.Compression.DeflateStream
  • System.IO.Compression.GZipStream
  • System.IO.FileStream
  • System.IO.Stream

Есть ли что-то, что мне не хватает, что даст мне возможностьиспользовать поток завершения ввода / вывода для хэширования файлов?Использует ли 7Zip SDK потоки завершения ввода-вывода?

Ответы [ 2 ]

0 голосов
/ 29 сентября 2010

Я бы рекомендовал изучить новую модель асинхронного программирования в F #. На эту тему есть отличное видео от MS TechEd 2010 в Новом Орлеане от Люка Хобана:

http://www.msteched.com/2010/NorthAmerica/DEV307

http://blogs.msdn.com/b/lukeh/archive/2010/06/13/f-scaling-from-explorative-to-net-component-f-talk-teched-2010.aspx

0 голосов
/ 29 сентября 2010

Во-первых, хотя .NET довольно неплох с точки зрения производительности, но если базовое требование - очень высокая производительность, я бы обратился к неуправляемому языку, скомпилированному на собственном языке, например C ++. JIT-компиляция и другие издержки CLR замедляют работу любого алгоритма, написанного на .NET.

Я думаю, что тысячи действительно одновременных запросов будут указывать на сильно распределенную модель; Прямо сейчас лучшее серверное оборудование на рынке (двухъядерные процессоры Xeon с двумя ядрами и гиперпоточностью) будет выполнять только 32 вещи одновременно, и прослушивание запросов на выполнение каких-либо задач, общение на аппаратном уровне и другие общие операционные / временные издержки потребуют до нескольких из них. Я бы проанализировал реальный трафик, который вы ожидаете обрабатывать этим сервером одновременно, и измерил бы количество ящиков, над которыми вы работаете, для соответствия.

Во-вторых, я думаю, что вы говорите, когда говорите, что «потоки завершения ввода-вывода» - это потоки, которые асинхронные вызовы Begin / End используют для своей работы, а не потоки из ThreadPool (избегайте в действительности потока - тяжелые приложения) или созданные пользователем темы (никаких проблем с ними, просто следите за количеством потоков). На самом деле, за исключением нескольких особых случаев, поток является потоком, и именно то, где он порождается, не имеет большого значения на аппаратном уровне, поэтому, если вы действительно этого хотите, порождение рабочих потоков, использующих синхронные вызовы, даст вам довольно почти тот же результат (но, как правило, лучше использовать инструменты, которые у вас есть, чем создавать новые).

Теперь к вашему настоящему вопросу. Нет, не существует асинхронной модели для хеширования; если вы хотите многопоточность операции хеширования, поток должен порождаться отдельно. Однако для хеширования требуется потоковый или байтовый буфер, который можно получить асинхронно с помощью Stream.BeginRead (), а метод обратного вызова, переданный в BeginRead (), может выполнить хеширование в потоке, порожденном асинхронным вызовом.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...