Проблема с производительностью «Клиент-сервер»

#java #performance #client

#java #Производительность #клиент

Вопрос:

У меня есть проблема «Теории очередей», в которой необходимо выполнить следующее:

  • Разработайте КЛИЕНТ для непрерывной отправки пакетов фиксированного размера на СЕРВЕР с фиксированной скоростью
  • СЕРВЕР должен поставить эти пакеты в очередь и ОТСОРТИРОВАТЬ их перед обработкой этих пакетов
  • Затем нам нужно доказать (для некоторого размера пакета ‘n’ байт и скорости ‘r’ Мбит / с) теоретическое наблюдение, что сортировка (n log n / CPU_FREQ) происходит быстрее, чем постановка в очередь (n / r), и, следовательно, ОЧЕРЕДЬ вообще не должна накапливаться.

Однако я нахожу, что очередь всегда накапливается (работает на двух системах — клиентских и серверных ПК / ноутбуках),

Примечание: Когда я запускаю процессы в одной и той же системе, очередь не создается, и большую часть времени она составляет от 1 до 20 пакетов.

Нужен кто-нибудь, чтобы проверить / просмотреть мой код.

Здесь вставлен код:

  1. Клиент (один класс):

  2. Сервер (пакет файлов нескольких классов: serverClasses:

  3. Примерный график для «QUEUE_LEN Vs. #PACKETS» для пакетов 10 Мбит / с и размером 10000 байт продолжительностью 30-35 секунд

введите описание изображения здесь

Комментарии:

1. Несколько быстрых вопросов / замечаний: Arrays.sort использует достаточно быстрый алгоритм сортировки для ваших нужд? Можно ли использовать другой алгоритм сортировки для более быстрой сортировки по типу данных, которые вы получаете? Почему вы вручную вызываете GC в своем классе сортировки?

2. Действительно странно, что очередь начинает заполняться при запуске клиента и сервера во взаимно удаленных системах, но очищается так же быстро, как и заполняется, когда клиент и сервер находятся в одной системе. Я бы ожидал, что введение задержки в сети даст серверу некоторое время для сортировки.

3. небольшое предложение, но вы должны использовать AtomicInteger для счетчиков GlobalStatistics, которые вы увеличиваете из нескольких потоков

4. @Freiheit я не совсем уверен, но предполагаю, что в JAVA был бы реализован хороший алгоритм сортировки (nlogn) для этой цели. GC предназначен для предотвращения ошибки JavaOutOfMemory при длительном запуске.

5. На клиенте мне кажется, что timeinterval всегда будет 0. Это было намерение? timeinterval = 1 / (numpackets...) и затем вы вызываете Thread.sleep(timeinterval) . Самое большее, это будет спать в течение 1 мс, если я не правильно читаю код. Вы говорите секунды, но вы никогда *1000 .

Ответ №1:

На клиенте мне кажется, что timeinterval всегда будет 0. Это было намерение? Вы говорите секунды в коде, но вам не хватает * 1000 .

 timeInterval = 1 / ( noOfPacketsToBeSent );
  

И затем вы вызываете Thread.sleep((long) timeinterval) . Поскольку sleep() принимает long , то это будет не более 1 мс сна и обычно (я подозреваю) 0 мс сна. Разрешение Sleep составляет всего миллисекунду. Если вам нужно разрешение в наносекундах, вам нужно будет сделать что-то вроде:

    TimeUnit timeUnit = TimeUnit.NANOSECONDS;
   ...
   timeUnit.sleep(50);  
  

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

По крайней мере, это мое лучшее предположение.

Комментарии:

1. Я думаю, что сейчас я вижу результаты! Большое спасибо за ваше время над моим кодом.