Tibco Rendezvous - ограничения размера

Question

Я пытаюсь помещать потенциально большую строку в сообщение с рандеву и интересовался ограничениями размера. Я понимаю, что в сообщение есть физический предел (64 Мб?), Но мне интересно, как некоторые другие переменные могут повлиять на него. В частности:

• Насколько велики ключи?
• Как строка хранится (в одном поле против нескольких полей)

Любые консультации по любой из вышеуказанных тем или что-нибудь еще, что могло иметь отношение было бы весьма признателен.

Примечание: Я хотел бы сохранить сообщение как необработанную строку (в отличие от байт-кода и т. Д.).

Answer 1

Из документов TIBCO на очень больших сообщений:

Rendezvous программное обеспечение может транспортировать самые большие сообщения; он делит их на небольшие пакеты и помещает их в сеть так же быстро, как сеть может принять их. В некоторых ситуациях это поведение может привести к перегрузке сети ; приложения могут достичь более высокой пропускной способности, деля большие сообщения на более мелкие куски и , регулирующие скорость, с которой он отправляет эти куски. Вы можете использовать инструмент для измерения производительности для оценки размеров корпусов и скорости передачи для оптимальной пропускной способности .

В этом примере отправлено одно сообщение , состоящее из десяти миллионов байт. Программное обеспечение Rendezvous автоматически делит сообщение на пакеты, и отправляет их. Однако этот всплеск пакетов может превысить пропускную способность сети, что приводит к снижению пропускной способности:

sender> rvperfm -size 10000000 -messages 1 

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

sender> rvperfm -size 10000 -messages 1000 -auto 

Изменяя параметры -messages и -size , вы можете определить оптимальный размер сообщения для ваших приложений в определенной сети. Разработчики приложений могут использовать эту информацию для регулирования скорости отправки для повышения производительности.

Как фактические пределы функции Add строка принимает строку C стиль ANSI, так что теоретически неограничен, но, учитывая подпись AddOpaque

tibrv_status tibrvMsg_AddOpaque( 
    tibrvMsg  message, 
    const char* fieldName, 
    const void* value, 
    tibrv_u32  size); 

который берет u32, казалось бы разумным утверждать, что предел, вероятно, будет 4 ГБ, а не 64 МБ.

То, что использование Tib для передачи таких больших пакетов, вероятно, будет серьезным узким местом в производительности, поскольку, возможно, оно должно буферизовать значительные объемы трафика, поскольку оно пытается получить эти сообщения всем потребителям. По умолчанию буфер rvd составляет всего 60 секунд, поэтому вы можете потерять потерю сообщения, если это значительный объем трафика.

Служебное сообщение в TIBCO во многом так же просто, как:

1. фиксированная стоимость, связанная с каждым сообщением (заголовок)
2. Все поля (тип информации и поле идентификатора)
3. Плюс стоимость всех переменных аспектов длины в том числе:
   1. передачи и приема субъектов (эффективно ограничивается до 256 байт каждый)
   2. фИ имена полей. Я не могу найти ограничений по длине имен полей в документах, но чем меньше они, тем лучше, они все еще не используют их вообще и используют числовые идентификаторы
   3. переменная array/string/opaque/user defined поля длины в сообщении

Примечание: Если вы используете вложенные сообщения просто рекурсию выше.

В вашем случае накладные расходы полезной нагрузки будут настолько обширными по сравнению с именами (при условии, что они разумны и просты), нет смысла пытаться их оптимизировать.

Возможно, вы можете значительно повысить эффективность проводки/буферизации, если вы передаете строки в сжатой форме, либо с использованием rvrd с включенным сжатием, либо путем изменения вашего производителя/потребителя, чтобы использовать что-то быстрое, но эффективное, как (или если вы чувствуете эзотерические вещи, такие как QuickLZ, FastLZ, LZO и т. д. Особенно те, у которых сжимаются/декомпрессионные системы с фиксированной памятью)

Вы не скажете, на какую платформу api вы нацеливаетесь (.net/java/C++/C, например), и это немного покрасит вещи. На проводнике все строковые данные будут по 1 байт на символ независимо от java/.net, используя UTF-16 по умолчанию, однако вы понесете значительную стоимость перевода, помещая их в/считывая их из сообщения, потому что базовый буфер нельзя использовать повторно в этих случаях и копия (и уплотнение/расширение соответственно) должны быть выполнены. Если вы придерживаетесь непрозрачных последовательностей байтов, у вас все еще будут накладные расходы на копирование наивных реализаций, доступных через api-интерфейс управляемой обертки, но это будет по меньшей мере меньше накладных расходов, если вам не нужно работать с данными в качестве родной строки.