Бечмарки для пакетов

7,099
324
1,509
Есть у кого бечмарки для тестирования времени отправки-приема пакетов? И что вообще нужно знать для тестирования сети?
 
7,099
324
1,509
Как синхронизировать время на сервере и клиенте? Допустим, если на удаленном хосте тестируется
 

tox1cozZ

aka Agravaine
8,454
598
2,890
Ну, во-первых, все модовые фордж пакеты не являются "срочными", поэтому складываются в очередь и обрабатываются на следующий тик. Уже проблема для бенчмарка, так как это до 50мс задержки.
Еще где-то глубоко (в протоколе?) есть кеширование пакетов, то есть сначала заполняется какой-то буфер, а только потом уже эти данные летят на удаленный хост (tcp_nodelay).

И для чего тебе это нужно?)
 
7,099
324
1,509
Хочу сравнить CCL и SimpleNetworkWrapper
 

sk9zist :l

Исправился
981
18
157
Вот тебе кусок моего кода: (хук и вывод всех пакетов в консоль)
Java:
@Hook(injectOnExit = true, returnCondition = ReturnCondition.ALWAYS)
public static void sendPacket(NetworkManager manager, Packet<?> packet)
{
    System.out.println("Packet Sent: " + packet.toString());
}
Потом получай всё что нужно (время или что там) из переменных manager и packet. Только боюсь отредактировать пакет ты не сможешь.
 
Последнее редактирование:
1,159
38
544
Я бы отсылал unix timestamp, а на стороне получателя вычислял разницу между текущем временем в секундах/милисекундах (в зависимости от требуемой точности) и пришедшим timestamp'ом

Однако если вы хотите по настоящему точных измерений, то стоит учесть несколько подводных камней:
  1. System.currentTimeMillis() и System.nanoTime() не отличаются только лишь единицами измерения. Первое обладает меньшей погрешностью по сравнению со вторым. В доках System.nanoTime() об этом упоминается так:
    This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary origintime (perhaps in the future, so values may be negative). The same origin is used by all invocations of this method in an instance of a Java virtual machine; other virtual machine instances are likely to use a different origin.
    This method provides nanosecond precision, but not necessarily nanosecond resolution (that is, how frequently the value changes) - no guarantees are made except that the resolution is at least as good as that of currentTimeMillis().

    Differences in successive calls that span greater than approximately 292 years (263 nanoseconds) will not correctly compute elapsed time due to numerical overflow.

    The values returned by this method become meaningful only when the difference between two such values, obtained within the same instance of a Java virtual machine, is computed.
  2. Не занимайтесь синхронизированием времени между клиентом и сервером. Это долго, вы сломаете себе мозг + это вообще не нужно. Вычисляйте разницу по времени на стороне получателя пакета, в который вкладывайте timestamp отправки.
  3. "Разогрейте" JVM на клиенте и сервере перед проведением замеров. Дело в том что один и тот же участок кода может показывать разную производительность на самом старте java-процесса и через минут 10-15. Это связано с происходящей под капотом JIT-компиляцией и вычислением внутренних хешей jvm.
  4. И самое главное - пожалуйста, не занимайтесь оценкой производительности кода netty (сетевой прослойки, отвечающей за пересылку и прием пакетов). Дело в том, что код отправки и приема пакетов - одна из самых частоисполняемых операций клиента и сервера, а потому являются первыми кандидатами на JIT-компиляцию (вкрадце, это механим с помощью которого JVM обнаруживает наиболее часто исполняемый код и прямо в рантайме перекомпилирует его в машинный платформозависимый код, стараясь ускорить выполняемую операцию). Как только код проходит JIT-компиляцию - код перестает быть вашим и вы не можете прямым образом влиять на его производительность, соответственно вы не можете гарантировать корректность результатов измерения. Вообще измерение производительности Java-приложений - это довольно трудная задача из-за динамической и изменяющейся природы JVM.
  5. Замеряйтесь производительность кода и сети на уровне всего приложения, а не его отдельных частей. Эта рекомендация связана с тем, что крайне тяжело измерить производительность отдельных взятых частей приложения, отделив их от остальных. Измеряя производтельности на уровне всего приложения вы существенно снижаете погрешности получаемых при измерении данных. Но если вы уж очень сильно хотите измерить кусок какого-то кода - используйте JMH. Использование System.currentTimeMillis() для оценки производительности существенно исказит результаты измерений. Скажу вам на 99.999% что для вашей задачи не нужны микробенчмарки для участков кода. Пожалуйста не занимайтесь этим.
  6. Для верных замеров используйте одну и ту же версию JVM для клиента и сервера
Анализ производительности Java-приложений - это крайне сложное дело, ребятки. Сложно не только собрать верные данные, но и не позволить себя ими одурачить. Эти рекомендации - мой пересказ книги "Java. Оптимизация программ. Практические методы повышения производительности приложений в JVM [2019]".
 
Последнее редактирование:

Icosider

Kotliner
Администратор
3,600
99
663
@RareScrap, даже если будут использовать жабовское время для замеров, то предпочтительней всё же наноТайм использовать, но это так к слову. А с остальным согласен, тоже эту книгу прочитал недавно.
 

jopi

Попрошайка
1,421
30
260
В чем проблема отсылать как нано тайм так и millis'ы?
А тем кому не в падлу можете попробовать вытянуть netServerHandler и засунуть пакет 250 в очередь под номером 0, или какие там у вас ныне аналоги существуют, netty чтоль
либо если с клиента на сервер та-же ситуация

в старых версиях очередью был ArrayList чисто
 
1,159
38
544
предпочтительней всё же наноТайм использовать
Почему так? Мне кажется что так делать как раз не нужно из-за высокой погрешности

отсылать как нано тайм так и millis'ы
Зачем оба-то? Достаточно одного из них. А если оба, то как использовать милисы для уменьшение погрешности нанотайма?

засунуть пакет 250 в очередь под номером 0
Что это за пакет?

в старых версиях очередью был ArrayList чисто
А сейчас как? Queue какая нибудь?
 

jopi

Попрошайка
1,421
30
260
@RareScrap нетхандлеры могли изчезнуть и появится что-то новое
250 пакет - CustomPayload был, скорее всего нужно думать над его аналогом
 
Сверху