Из документов Tibco об очень больших сообщениях:
Программное обеспечение Rendezvous может передавать очень большие сообщения; он делит их на небольшие пакеты и размещает в сети так быстро, как только сеть может их принять. В некоторых ситуациях такое поведение может привести к перегрузке пропускной способности сети; приложения могут достигать более высокой пропускной способности, разделяя большие сообщения на более мелкие фрагменты и регулируя скорость, с которой они отправляют эти фрагменты. Вы можете использовать инструмент производительности для оценки размеров фрагментов и скорости отправки для оптимальной пропускной способности.
В этом примере отправляется одно сообщение, состоящее из десяти миллионов байтов. Программное обеспечение Rendezvous автоматически делит сообщение на пакеты и отправляет их. Однако этот пакет пакетов может превысить пропускную способность сети, что приведет к снижению пропускной способности:
sender> rvperfm -size 10000000 -messages 1
Во втором примере приложение делит десять миллионов байтов на одну тысячу меньших сообщений по десять тысяч байт каждое и автоматически определяет размер пакета и интервал, чтобы регулировать поток для достижения оптимальной пропускной способности:
sender> rvperfm -size 10000 -messages 1000 -auto
Изменяя параметры -messages и -size, вы можете определить оптимальный размер сообщения для ваших приложений в конкретной сети. Разработчики приложений могут использовать эту информацию для регулирования скорости отправки для повышения производительности.
Что касается фактических ограничений, функция Add string принимает строку ansi в стиле C, поэтому теоретически она не ограничена, но, учитывая сигнатуру AddOpaque
tibrv_status tibrvMsg_AddOpaque(
tibrvMsg message,
const char* fieldName,
const void* value,
tibrv_u32 size);
который использует u32, было бы разумно указать, что ограничение, вероятно, будет 4 ГБ, а не 64 МБ.
Тем не менее, использование Tib для передачи таких больших пакетов, вероятно, будет серьезным узким местом в производительности, поскольку ему, возможно, придется буферизовать значительные объемы трафика, поскольку он пытается доставить такие сообщения всем потребителям. По умолчанию буфер rvd составляет всего 60 секунд, поэтому вы можете столкнуться с потерей сообщений, если это значительный объем вашего трафика.
Накладные расходы сообщений в tibco в основном так же просты, как:
- фиксированная стоимость, связанная с каждым сообщением (заголовок)
- Все поля (информация о типе и идентификатор поля)
- Plus the cost of all variable length aspects including:
- the send and receive subjects (effectively limited to 256 bytes each)
- имена полей. Я не могу найти ограничения на длину имен полей в документах, но чем они меньше, тем лучше, а лучше вообще не использовать их и использовать числовые идентификаторы.
- массив/строка/непрозрачные/определяемые пользователем поля переменной длины в сообщении
Примечание. Если вы используете вложенные сообщения, просто повторите приведенное выше.
В вашем случае накладные расходы на полезную нагрузку будут настолько огромными по сравнению с именами (если они разумны и просты), что нет смысла вообще пытаться их оптимизировать.
Вы можете обнаружить, что можете значительно повысить эффективность проводной/буферизованной передачи, если будете передавать строки в сжатой форме, либо за счет использования rvrd с включенным сжатием, либо путем изменения вашего производителя/потребителя на использование чего-то быстрого, но эффективного, например, deflate (или, если вы чувствуете эзотерические вещи, такие как QuickLZ, FastLZ, LZO и т. Д. Особенно с фиксированным объемом памяти, сжимающим / распаковывающим механизмы)
Вы не говорите, на какую платформу API вы ориентируетесь (например, .net/java/C++/C), и это немного окрасит ситуацию. В сети все строковые данные будут в 1 байте на символ, независимо от java/.net, использующего UTF-16 по умолчанию, однако вы понесете значительные затраты на перевод, помещая их в/считывая их из сообщения, потому что базовый буфер не может быть повторно использован в этих случаях необходимо выполнить копирование (и соответственно сжатие/расширение). Если вы придерживаетесь непрозрачных последовательностей байтов, у вас все еще будут накладные расходы на копирование в наивных реализациях, возможных через API-интерфейс управляемой оболочки, но это, по крайней мере, будет меньше накладных расходов, если вам не нужно работать с данными как с собственной строкой.
person
ShuggyCoUk
schedule
07.12.2009
