Распределение времени ожидания между запросами на соединение и проблемами с производительностью - PullRequest
Новая
       4

Распределение времени ожидания между запросами на соединение и проблемами с производительностью

2 голосов
/ 30 ноября 2011

Я разработал сервер для нестандартного протокола на основе tcp / ip-stack с Netty. Писать это было приятно.

Сейчас я тестирую производительность. Я написал тестовое приложение для netty, которое просто подключает множество (более 20 000) «клиентов» к серверу (цикл for с Thread.wait (1) после каждого загрузочного соединения). Как только клиент-канал подключен, он отправляет запрос входа в систему на сервер, который проверяет учетную запись и отправляет ответ входа в систему.

Общая производительность, похоже, вполне нормальная. Все клиенты вошли ниже 60-х годов. Но что не так хорошо, так это распределенное время ожидания на соединения. У меня очень быстрые логины и очень медленные логины. Различия от 9 мс до 40 000 мс распространяются на все время тестирования. Можно ли как-то разделить время ожидания между запрашивающими каналами (Fifo)?

Я измерил много значительных временных меток и обнаружил странное явление. У меня много подключений, где временная метка сервера «подключена к каналу» намного больше временной метки клиента (до 19 секунд). У меня также есть «нормальный» случай, когда они совпадают, и просто время между отправкой клиента и получением сервера составляет несколько секунд. И есть случаи всего между этими двумя случаями. Как может быть так, что клиент и сервер, «соединенные каналом», находятся на большом расстоянии друг от друга?

Что точно, так это то, что клиент немедленно получает логин-ответ сервера после его отправки.

Настройка: Я думаю, что я прочитал большинство статей о производительности здесь. Я использую OrderMemoryAwareThreadPool с 200 потоками на 4CPU-Hyper-Threading-i7 для входящих соединений, а также запускаю серверное приложение с известными агрессивными параметрами. Я также полностью настроил свой Win7-TCP-Stack. Сервер работает очень гладко на моей машине. Загрузка процессора и потребление памяти составляет ок. на 50% от того, что можно было бы использовать.

Слишком много информации: Я также запустил 2 моих тестовых приложения с 2 отдельных машин, которые «атаковали» сервер параллельно с 15 000 подключений в каждом. Там у меня было около 800 соединений, которые получили тайм-аут с сервера. Любые комментарии здесь?

С наилучшими пожеланиями и поздравлениями Нетти, Martin

1 Ответ

2 голосов
/ 01 декабря 2011

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

Если вы считаете, что он работает намного хуже, чем не- Нетти приложение, пожалуйста, не стесняйтесь подать проблему с воспроизведением тестового примера.Мы постараемся воспроизвести и исправить проблему.

...