Мы наблюдаем поведение, при котором производительность JVM снижается при небольшой нагрузке. В частности, при многократных запусках в тестовой среде мы замечаем, что задержка ухудшается примерно на 100%, когда скорость сообщений о заказах, закачиваемых в систему, уменьшается. Ниже приведены некоторые предыстории проблемы, и я был бы признателен за любую помощь по этому вопросу.
Упрощенно можно предположить, что исследуемое демо-приложение для торговли на Java имеет 3 важных потока: поток получателя ордеров, поток процессора, передатчик обменапоток
Поток получателя заказа получает заказ и помещает его в процессор q. поток процессора забирает его из процессора q, выполняет некоторую базовую обработку и помещает его в обмен q. Поток передатчика обмена забирает его с биржи q и отправляет заказ на биржу.
Задержка от получения заказа до выхода заказа на биржу ухудшается на 100%, когда скорость заказов, закачиваемых в системуизменяется с большего числа на низкое.
Испытанные решения:
Прогрев критического пути кода в JVM путем отправки высокой частоты сообщений и заполнения системы перед уменьшениемчастота сообщений: не решает проблему
Профилирование приложения: используя профилировщик, он показывает горячие точки в коде, где улучшение может быть на 10-15% за счет улучшения реализации. Но ничто в пределах 100% -ого улучшения не достигается только за счет увеличения частоты сообщений.
У кого-нибудь есть идеи или предложения по этому поводу? Может ли это быть связано с джиттером планирования в потоке.
Может ли быть так, что при низкой скорости сообщений потоки переключаются из ядра?
2 сообщения, я думаю, может бытьсвязанные ниже. Однако наши симптомы немного отличаются:
быстрее JVM под нагрузкой?
Почему JVM требует прогрева?