Именованная производительность трубы

  • У меня есть приложение, куда я отправляю ок. 125 элементов данных через именованный канал.
  • Каждый элемент данных состоит из блока данных 1 с макс. 300 знаков и блок данных 2 с макс. 600 знаков.
  • Это дает 125 элементов данных * (300 + 600) символов * 2 байта на символ = 125 * 900 * 2 = 225000 байтов.
  • Каждый элемент данных заключен в фигурные скобки, например {Message1}{Message2}.
  • Я заметил, что если я отправляю сообщения, возникают проблемы с отправкой / получением. Вместо {Message1}{Message2} принимающее приложение получает {Messa{Message2}.
  • Затем я изменил код отправки, чтобы сообщения отправлялись с интервалом в 500 мс. Потом проблема исчезла.

Если я все сделаю правильно (без ошибок с моей стороны, без неправильной настройки именованных каналов), сколько времени потребуется для отправки 225000 байт по именованному каналу из приложения в Delphi 2009 в приложение в .NET на той же машине?

Какое разумное время для отправки данных такого размера?


person Mentiflectax    schedule 08.11.2012    source источник
comment
Похоже, ваш код ошибочен. Вам следует сконцентрироваться на поиске и исправлении недостатка. Добавление «сна» - это просто бумажки поверх трещин. Найдите и устраните настоящую проблему.   -  person David Heffernan    schedule 08.11.2012
comment
Попробуйте здесь хорошую библиотеку IPC, Cromis-IPC.   -  person LU RD    schedule 08.11.2012
comment
Вовлечены ли потоки? Именованный канал будет отправлять и получать именно то, что вы положили, в том порядке, в котором вы его поместили. В вашем коде есть логическая проблема, поэтому, пожалуйста, убедитесь, что с моей стороны нет ошибок, поскольку это неправда.   -  person mj2008    schedule 08.11.2012
comment
Если вы смотрите на скорость, самое быстрое решение - это разделяемая память, а не именованные каналы. (Производительность IPC: именованная труба против сокета)   -  person mjn    schedule 08.11.2012
comment
Как сказал @ mj2008, если у вас есть несколько потоков на отправляющей стороне, убедитесь, что только один поток отправляет все сообщение в канал. Тем временем другие потоки должны подождать.   -  person iPath ツ    schedule 08.11.2012
comment
Есть только одна ветка. Сначала я составляю список строк (TStringList), затем отправляю все строки одну за другой.   -  person Mentiflectax    schedule 08.11.2012
comment
Каждая строка представляет одно сообщение.   -  person Mentiflectax    schedule 08.11.2012
comment
Используйте что-то вроде Codesite для вывода того, что вы отправляете и что получаете. Очень поможет логгер низкого уровня.   -  person mj2008    schedule 08.11.2012
comment
@ mj2008 Я уже это делаю. Приложение Delphi отправляет правильные сообщения, но иногда сообщения доставляются неправильно (часть сообщения теряется). На принимающей стороне есть только один поток, который читает данные из именованного канала. Ошибки с отправкой / получением можно исправить, изменив размер буфера именованного канала.   -  person Mentiflectax    schedule 08.11.2012
comment
Что дает вам такую ​​уверенность в правильности кода?   -  person David Heffernan    schedule 08.11.2012
comment
Хорошо, так что по одной нити в обе стороны. Они работают одновременно? Похоже, вы просто достигли пределов буфера в трубе. Если считыватель работает не так быстро, как писатель, а буфер слишком мал и нет синхронизации, то это произойдет. Ожидание подтверждения по возврату (возможно, с окном, позволяющим считывающему устройству отставать на 10 пакетов), похоже, здесь уместно.   -  person mj2008    schedule 08.11.2012
comment
@ mj2008 По поводу слишком маленького размера буфера: как я могу рассчитать оптимальный размер буфера (кроме как методом проб и ошибок)?   -  person Mentiflectax    schedule 08.11.2012
comment
Разместите свой код, и мы найдем ошибку. :-)   -  person Harry Johnston    schedule 12.11.2012
comment
@ Дмитрий Писаренко - оптимальный размер буфера в Windows с современным процессором Intel в пользовательском пространстве - это страница размером 4 КБ, выровненная по 64-байтовой границе.   -  person hoodaticus    schedule 14.10.2015