Весенняя интеграция обработка больших соединений
Мы внедрили TCP-сервер с интеграцией Spring.
Конфигурацию сделал как
@Bean
TcpNetServerConnectionFactory cf(){
TcpNetServerConnectionFactory connectionFactory=new TcpNetServerConnectionFactory(TCP_PORT);
connectionFactory.setSerializer(new CustomSerializerDeserializer());
connectionFactory.setDeserializer(new CustomSerializerDeserializer());
connectionFactory.setSoTimeout(TIMEOUT);
return connectionFactory;
}
@Bean
TcpInboundGateway tcpGate(){
TcpInboundGateway gateway=new TcpInboundGateway();
gateway.setConnectionFactory(cf());
gateway.setRequestChannel(requestChannel());
return gateway;
}
@Bean
public MessageChannel requestChannel(){
return new DirectChannel();
}
И активатор услуги
@MessageEndpoint
public class Echo {
@ServiceActivator(inputChannel = "requestChannel")
public byte[] echo(byte[] in,@SuppressWarnings("deprecation") @Header("ip_address") String ip){
return "OK".getBytes();
}
}
У нас более 150 соединений с назначенным портом и более 150 TCP-пакетов каждые 10 секунд.
В настоящее время мы имеем дело с проблемой позднего получения пакетов. Нам требуются данные в реальном времени для нашей работы.
Недавно мы пришли к выводу, что потоки ожидают выполнения, что приводит к позднему получению пакета.
Как мы можем справиться с такими проблемами с помощью Spring Integration и tcp inboudgateways.
Ответы 2
TcpNetServerConnectionFactory является подклассом AbstractConnectionFactory, который определяет свойство java.util.concurrent.Executor (taskExecutor).
Извините, я не знаю, что означает большой. Также имейте в виду, что Executor просто выполняет задачи. Само по себе оно не имеет никакого отношения к связям любого рода.
Хорошо. Позвольте мне объяснить сценарий: у нас более 150 подключений через TCP-порт, и каждый клиент отправляет пакет данных каждые 10 секунд. Мы заметили, что пакеты данных, полученные активатором службы, опаздывают достаточно поздно, чем ожидалось. Время задержки увеличивалось по мере увеличения нагрузки.
Позвольте мне попробовать это по-другому. Вы описываете сценарий, где кажется, что введение более высокого уровня параллелизма может помочь, поэтому я предлагаю добавить исполнителя (например, ThreadPoolTaskExecutor) с более высоким пулом потоков. Теперь это само по себе может не помочь, так как зависит от многих факторов (как аппаратных, так и программных). Я не знаю этих факторов, так как я не знаю вашего окружения, поэтому я не могу строить дальнейшие предположения. Говорить что-то «большое» в этом контексте бессмысленно.
вместо большого мы можем сказать, что это слишком много соединений. не вопрос, спасибо за помощь. Я попытаюсь реализовать CompositeExecutor для этого сценария. Если вы знаете об этом, пожалуйста, помогите нам.
Вместо этого попробуйте использовать TcpNioServerConnectionFactory.
Вместо этого используйте TcpNioServerConnectionFactory; ...Net... более эффективен для небольшого количества длительных соединений.
Но см. эта глава в справочном руководстве.
Спасибо, Гэри. Способен ли исполнитель задач по умолчанию обрабатывать любое количество запросов или нам нужно добавить собственный исполнитель задач?
Да; исполнитель задач по умолчанию имеет неограниченное количество потоков, так что это не должно быть проблемой ни для одной из фабрик соединений. На самом деле вы не описываете природу ваших «поздних пакетов», но имейте в виду, что это гораздо больше, чем просто обработка ввода-вывода сокета, например, если процессоры заняты обработкой сообщений из других сокетов, или, возможно, есть некоторая синхронизация кода это вызывает узкое место. Вам нужно посмотреть на использование вашего ЦП и / или профилировать ваше приложение, чтобы выяснить, почему оно не обрабатывает скорость сообщений, которая вам нужна. 15 сообщений в секунду — это очень низкая скорость передачи сообщений.
Вы правы, проблема с подключением может быть не там. Я предполагаю, что обработка пакетов может занимать много времени. Мы используем собственный сериализатор и десериализатор для дифференциации пакетов, а также используем прямой канал, не будет ли это причиной позднего получения данных?
Я понятия не имею о вашем коде, вам придется его профилировать; DirectChannel добавляет очень мало накладных расходов.
Спасибо за ваш ответ. Способен ли исполнитель задач по умолчанию обрабатывать большие соединения?