WCF NetTcpBinding Buffered vs Потоковые проблемы с производительностью

Question

Я написал службу WCF, которая должна преобразовывать файлы любого размера, используя Streamed TransferMode в NetTcpBinding и System.IO.Stream объект.

При выполнении теста производительности обнаружена значительная проблема с производительностью. Затем я решил протестировать его с помощью Buffered TransferMode и увидел, что производительность в два раза выше!

Поскольку моя служба должна передавать большие файлы, я просто не могу оставаться в Buffered TransferMode из-за накладных расходов на управление большими файлами на стороне сервера и клиента вместе.

Почему Streamed TransferMode медленнее, чем Buffered TransferMode? Что я могу сделать, чтобы улучшить производительность Stremed?

Answer 1

Насколько большие куски вы транслируете? Вы можете экспериментировать с разными размерами чанков и разными стратегиями.
Также рассмотрите возможность использования Asynch IO для заполнения буферов, подлежащих передаче или после передачи.

Что я имею в виду, если ваш алгоритм потоковой передачи последовательный, например:

1. Fill a chunk
2. send the chunk
3. get confirmation
4. more chunks?  Go to step 1

... тогда у вас много ненужных задержек. Если вы сможете заполнять блоки и отправлять их параллельно, вы сможете сократить время ожидания. Async IO - один из способов сделать это. У вас будет два параллельных рабочих потока. Концептуально это может выглядеть так:

Filling Chunks                              Sending Chunks
  1. call BeginRead                           1. get next chunk
  2. wait for callback                        2. send it
  3. more to read? yes -> go to step 1        3. await confirmation
  4. done                                     4. more? go to step 1

Но используя Async IO, они могут фактически управляться одним и тем же потоком.

Имейте это в виду:

Читали ли вы статью MS на тему потоковой передачи больших данных в WCF?