Трудно ответить, основываясь на этом описании.
Если вы написали клиента, который пытается вести себя как многие клиенты, это действительно не клиент. И если он работает в той же системе, что и сервер, он, очевидно, будет мешать ему.
Что касается изолированного сервера, то что влияет на задержку?
1. Как долго сетевой уровень (часть платформы и, следовательно, вне вашего контроля) реагирует на входящий пакет.
2. Как долго поток ввода-вывода, обслуживающий сокеты (я предполагаю, что здесь TCP), должен ждать, прежде чем он начнет работать, учитывая, что он конкурирует с другими потоками.
3. Сколько сокетов имеют события. Поток ввода-вывода должен обрабатывать каждый из них, поэтому некоторые из них будут обработаны раньше, чем другие. Поток должен превратить поток каждого клиента в серию рабочих элементов и поставить их в очередь для рабочего потока вместо того, чтобы обрабатывать их самостоятельно.
4. Как долго рабочий элемент находится в рабочей очереди, прежде чем он будет обработан. Рабочий поток, который обрабатывает его, может отправить ответ непосредственно клиенту.
Это лучшее, что ты можешь сделать. Вы можете пометить рабочий элемент, когда он будет создан и поставлен в очередь, чтобы увидеть, как долго он ждал, прежде чем рабочий поток обработал его, и вы можете собрать статистику из этого. Вы также можете посмотреть на загрузку процессора, чтобы увидеть, не перегружается ли сервер (100% загрузка процессора). Использование кучи вряд ли будет фактором, за исключением того, что чем больше занят сервер, тем больше занят сборщик мусора.
Может быть, я зря потратил здесь время, потому что я предполагаю, что вы можете изменить сервер. Если это какой-то код черного ящика, то он должен предоставлять те виды статистики, о которых я говорю, если это что-то другое, чем демонстрация игрушек.
Edit: ничто здесь на самом деле не является "узким местом", пока сервер не работает со 100% - ной загрузкой процессора. На этом этапе речь идет об упорядочении кода. Кроме того, если работа от клиентов может быть классифицирована как "новая" или "прогресс", то сервер может реализовать политику управления перегрузкой, которая отклоняет (или просто молча выбрасывает) новую работу, чтобы поддерживать хорошее обслуживание клиентов, которые уже были приняты.
"Если вы написали клиента, который пытается вести себя как многие клиенты, это действительно не клиент. И если он работает в той же системе, что и сервер, он, очевидно, будет мешать ему". - он не работает в той же системе, это другой компьютер.
Куча не может быть фактором? когда я запускаю много потоков, диаграмма использования кучи выглядит как очень плотная пилообразная волна.
"Ничто здесь на самом деле не является "узким местом", пока сервер не работает со 100% - ной загрузкой процессора" - не могли бы вы подробнее остановиться на этом ?
Да, куча будет выглядеть как пилообразная волна из-за сбора мусора.
Если на сервере есть свободное процессорное время, то как может быть узкое место? Исключением может быть сервер, который, скажем, привязан к диску и ожидает завершения чтения с диска (например, изображений).
"Да, куча будет выглядеть как пилообразная волна из-за сбора мусора." - Я знаю, но когда алгоритм сборщика мусора выполняется, он поглощает процессор, не так ли?
Когда GC вызывается часто, это может означать задержку при обработке правильных данных. Разве я не прав ?
Да, GC использует процессорное время, и обычно больше, если система занята. Так что вы правы, это влияет на задержку. Вот почему серьезные серверы не используют его. Но ты мало что можешь с этим поделать.
"Вот почему серьезные серверы не используют его" хм, нет GC?
так что вместо ГК ?
Иногда я говорю вещи, которые слишком черно-белые. :)
Вероятно, есть серверы, которые используют GC, но это может быть рискованно. Я бы использовал C++ для серьезного сервера, и у него нет GC. Существует небольшая разница между очисткой ссылки и освобождением базовой памяти без ожидания GC. Когда кто-то забывает очистить ссылку или удалить объект, в идеале вы хотите обнаружить утечку памяти и исправить ее. Я написал статью robust C++: Object Pools о том, как это сделать в C++. Но я не думаю, что то, что он описывает, может быть сделано на Java.