Автор оригинала: Vlad Mihalcea.
Я только что вернулся с семинара по производительности Java, проведенного Питером Лоури в Клуж-Напока ЭТО Дни .
Питер Лоури является известным пользователем Java StackOverflow и создателем Java Chronicle библиотеки с открытым исходным кодом.
Закон Литтла определяет параллелизм как:
Для увеличения пропускной способности мы можем либо:
- увеличение ресурсов сервера (масштабирование по вертикали или горизонтали)
- уменьшите задержку (повысьте производительность)
В то время как корпоративные приложения обычно предназначены для скальпинга, торговые системы фокусируются на снижении задержек.
Как бы удивительно это ни звучало, большинство торговых систем, о которых я слышал, на самом деле написаны на Java. Автоматическое управление памятью Java-это обоюдоострый меч, поскольку он обменивает простоту на гибкость.
Система с низкой задержкой хуже кошмара-это процесс остановки мира, как сборщик мусора. Поэтому, чтобы избежать таких ситуаций, вы должны уйти в отрыв.
Java напрямую не предлагает управление памятью вне кучи, поэтому вам приходится прибегать к неортодоксальным методам, таким как взаимодействие с sun.разное. Небезопасно класс.
Как ясно следует из его названия, вы не должны использовать этот класс в первую очередь. Этот класс позволяет обойти многие механизмы безопасности JVM, поэтому вы можете:
- выделение памяти вне кучи
- определение классов без фактического загрузчика классов
- переназначение данных памяти, даже констант
Этот класс не предназначен для использования большинством профессионалов Java, поскольку он в основном полезен для сгибания ложки библиотек, таких как:
Для торговых систем с низкой задержкой вы не можете использовать какую-либо готовую систему обмена сообщениями. Чтобы достичь 20 миллионов в секунду, вам нужно высокопроизводительное решение для организации очередей.
Java Chronicle-гораздо лучшая альтернатива использованию файлов с отображением в памяти с помощью sun.разное. Небезопасно API. Короче говоря, Java Chronicle позволяет производительному процессу записывать данные в общую ячейку памяти только для того, чтобы их использовал какой-либо другой процесс.
Таким образом, Java Chronicle больше похожа на файловую утилиту с отображением в памяти, чем на реальную систему обмена сообщениями. Поэтому, если вы планируете подключить два отдельных приложения, работающих в одном и том же окне, вам обязательно следует попробовать эту библиотеку с низкой задержкой.
В то время как вы всегда должны стремиться к минимально возможной задержке, корпоративное приложение требует совершенно другого решения для организации очередей. Корпоративная система состоит из нескольких приложений, которые должны быть взаимосвязаны, и эти приложения могут находиться на разных узлах.
Таким образом, корпоративная система обмена сообщениями в первую очередь должна быть предназначена для работы в сети. По сравнению с задержками торговых систем (микросекунды), задержки в сети намного выше (миллисекунды).
Корпоративная очередь должна иметь дело как с несколькими производителями, так и с несколькими потребителями. Некоторые системы используют брокеров для подтверждения используемых сообщений (например, JMS), в то время как другие системы делегируют смещения чтения сообщений на сторону потребителя (Apache Kafka).
Apache Kafka -это решение для обмена сообщениями с публикацией и подпиской, основанное на распределенном журнале фиксации. Таким образом, в то время как Java Chronicle увеличивает пропускную способность за счет уменьшения задержки, Кафка вместо этого использует распределенное масштабирование.