sof.bix пишет: > > нужно решить насколько имеет смысл жертвовать удобством ради > сомнительной эффективности. Для этого стоит провести хотя бы примитивное > нагрузочное тестирование. > > Вопрос стоит даже в реализации на нативном коде, настолько сильны > требования к производительности, сейчас собираются сведения по > производительности, поскольку тесты отнимут много времени которого > сейчас столько же сколько денег
Позволю себе дать совет нетехнического характера — если времени и денег
настолько мало, что их не хватает даже на написание теста приблизительно
эмулирующего нагрузку, лучше забейте на этот проект.
Принимая решение на основе "сведений" (почёрпнутых с форумов?) вы очень
сильно рискуете.
Здравствуйте, sof.bix, Вы писали:
SB>Не нашел чтобы тему поднимали, но интересует вопрос: насколько различные реализации JMS утежеляют передачу сообщений между узлами в сравнении с Socket TCP + protobuf. Интересуют в особенности реализация входящая в комплект JBOSS и сервер ActiveMQ. Интересует нагрузка не только на канал передачи данных но и на ресурсы сервера. Заранее всем спасибо!!! И с женским праздником ВСЕХ!
В последний раз когда я мерил на 200 байт пересылаемого добавлялось 80 байт оверхэда.
Предполагаю что если использовать сериализацию отличную от стандартной яваской, например Jboss Serialization то можно эту цифру уменьшить
Здравствуйте, sof.bix, Вы писали:
SB>Не нашел чтобы тему поднимали, но интересует вопрос: насколько различные реализации JMS утежеляют передачу сообщений между узлами в сравнении с Socket TCP + protobuf. Интересуют в особенности реализация входящая в комплект JBOSS и сервер ActiveMQ. Интересует нагрузка не только на канал передачи данных но и на ресурсы сервера.
Что-то я не понял какая проводится параллель? Socket TCP + protobuf — обычный Remoting, JMS — асинхронная обработка\передача сообщений. При особом желании второе можно попробовать пустить поверх первого. ИМХО, разные уровни OSI модели.
Здравствуйте, sof.bix, Вы писали:
SB>Не нашел чтобы тему поднимали, но интересует вопрос: насколько различные реализации JMS утежеляют передачу сообщений между узлами в сравнении с Socket TCP + protobuf. Интересуют в особенности реализация входящая в комплект JBOSS и сервер ActiveMQ. Интересует нагрузка не только на канал передачи данных но и на ресурсы сервера. Заранее всем спасибо!!! И с женским праздником ВСЕХ!
Вообще говоря, голый низкоуровневый TCP в любом случае будет эффективнее, чем надстройки более высокого уровня. С другой стороны, Вам нужно решить насколько имеет смысл жертвовать удобством ради сомнительной эффективности. Для этого стоит провести хотя бы примитивное нагрузочное тестирование.
Не нашел чтобы тему поднимали, но интересует вопрос: насколько различные реализации JMS утежеляют передачу сообщений между узлами в сравнении с Socket TCP + protobuf. Интересуют в особенности реализация входящая в комплект JBOSS и сервер ActiveMQ. Интересует нагрузка не только на канал передачи данных но и на ресурсы сервера. Заранее всем спасибо!!! И с женским праздником ВСЕХ!
Здравствуйте, Blazkowicz, Вы писали:
B>Что-то я не понял какая проводится параллель? Socket TCP + protobuf — обычный Remoting, JMS — асинхронная обработка\передача сообщений. При особом желании второе можно попробовать пустить поверх первого. ИМХО, разные уровни OSI модели.
Попробую объяснить, сильно не ругайте, поскольку с локальной сетью только начал работать и много не знаю.
Почитав про абстрактные OSI я понял: Socket TCP + protobuf обеспечивает 6-й уровень представления-передачи данных, JMS — 7-й для модели OSI, правда условно. Так вот хочется достичь промежуточного результата. Когда сервер является управляющим всеми клиентами (по факту соединения сокетов, на самом деле это slave server's), неким рабовладельцем, который распределяет между клиентами нагрузку. Так вот необходимо организовать между клиентами и сервером событийно-асинхронную модель оповещения. Насколько я понял ActiveMQ как раз по умолчанию реализует "второе пустить по первому". Интересно насколько много оверхедов на больших данных 25-100Мбайт
Спасибо
ЛИ>Вообще говоря, голый низкоуровневый TCP в любом случае будет эффективнее, чем надстройки более высокого уровня. С другой стороны, Вам нужно решить насколько имеет смысл жертвовать удобством ради сомнительной эффективности. Для этого стоит провести хотя бы примитивное нагрузочное тестирование.
Вопрос стоит даже в реализации на нативном коде, настолько сильны требования к производительности, сейчас собираются сведения по производительности, поскольку тесты отнимут много времени которого сейчас столько же сколько денег
Здравствуйте, Сеня Белдыев, Вы писали:
СБ>В последний раз когда я мерил на 200 байт пересылаемого добавлялось 80 байт оверхэда. СБ>Предполагаю что если использовать сериализацию отличную от стандартной яваской, например Jboss Serialization то можно эту цифру уменьшить
а чем передавали? И какую информацию содержал блок?
У меня скорее всего будет до 100 Мб, текста в основном
