Есть еще например такая оптимизация. Письма на столе могут лежать неаккуратно и занимать много места. Более того, часть писем лежат в каких-то больших запечатанных конвертах. В этом случае чтобы положить на стол новое письмо надо сначала убрать самое старое с поверхности стола в ящик. Если письмо запечатано в большой красивый дизайнерский конверт, то его приходится оттуда для начала достать. Тут поможет несколько вещей. Во-первых, письма надо складывать поаккуратнее, чтобы большее их количество влезло на поверхность стола. Во-вторых, их стоит доставать из лишних упаковок, чтобы они занимали меньше места и чтоб сотрудникам, которые будут их читать, не требовалось делать это самостоятельно. В-третьих, стоит увеличить поверхность стола по возможности. При этом увеличение количества ящиков в столе не особо поможет. Главное чтобы ящики легко выдвигались. А лучше вообще избежать их использования.
Да, действительно, я ошибся. Ну так или иначе мы используем не стандартный ThreadLocal, а самодельную реализацию на основе сгенерированного кода, которая судя по jmh бенчмаркам раза в два быстрее. Можно будет про нее отдельно написать как-нибудь.
Да, задумывались. Дело ведь не только в языке, но и в рантайме. JVM под Linux довольно неплохо оптимизированы. Как обстоят дела у проекта Mono я не особо в курсе.
В первую очередь важно не среднее значение, а правый хвост распределения. К сожалению, настройкой GC обойтись не получалось, поэтому пришлость начать экономить на аллокациях.
Наш ориентир по latency — 50 мкс. Насчет другого языка — да, можно писать на нативном языке. Но у java есть неоспоримые плюсы: удобные фреймворки для тестирования кода, удобные IDE для разработки, куча библиотек для всего чего угодно, которыми вполне можно пользоваться вне критического пути, высокая скорость разработки. По факту обо всех тех же вещах придется думать и при программировании на условных плюсах. malloc на критическом пути в любом случае не вызывается, так что придется в подобных вещах упражняться.
В интернете есть довольно много подобных бенчмарков. Например вот. Нужно ли тянуть в ваш проект дополнительные зависимости — это вам решать. Тем не менее, если есть задача избавиться от лишнего мусора, то выбора не остается.
Да, описанных мер не достаточно. По факту, приходится отказываться от использования на критическом пути практически всех привычных для большинства разработчиков библиотек. Конечно, это сильно ограничивает. Мы тоже пришли к тому, что весь критический путь вынесен в одну или несколько JVM, в которых мусорить практически запрещено. Вся остальная обвязка, не критичная к latency, вынесена в отдельные JVM. Там можно и мусорить, и блокироваться сколько влезет.
P.S. Минута — очень длинный промежуток времени. Это уже территория high throughput.
Да, никаких новых/экзотических фич языка тут нет, обычная Java. Я даже Unsafe ни разу не упомянул. Идея поста в том, чтобы показать как выглядит стиль garbage free программирования. В таком стиле написано довольно мало библиотек. И нужно это далеко не во всех ситуациях. Тем не менее, такой стиль является насущной необходимостью в случае если SLA для worst case latency на весь сетевой стек и бизнес логику системы составляет десятки микросекунд.
Это отличный подход, так можно делать. Пользуясь случаем не могу не прорекламировать отличный инструмент для этого: SBE. К сожалению, это не всегда удобно. Пример: объект, который мы хотим переиспользовать хранит ссылки на другие объекты. В этом случае придется придумывать разные варианты, которые могут быть менее предпочтительны. 1) Сериализовать в этот же буфер объект, на который ссылаемся, и работать с локальной копией. Это иногда имеет смысл, но не всегда, особенно если состояние объекта может меняться извне. 2) Можно хранить объекты, на которые мы ссылаемся, в неком массиве/списке, а в буфер записывать только индекс в этом массиве. В этом случае у нас нет ссылки на сам этот массив/список в буфере, и мы должны либо делать его статическим, либо ссылка на него должна быть доступна из контекста.
Интересная статья. Судя по тому, что на 56 ядрах работают 200 потоков, блокирующие операции все-таки имеются. И я подозреваю, что это блокирующим является jni вызов sendfile. Небольшое гугление показывает, что у sendfile есть асинхронный аналог под FreeBSD, разработанный компанией Netflix. Очевидно, у них в этом же месте был ботлнек. Возможно под линуксом это тоже уже появилось, но я не в курсе.
Есть еще например такая оптимизация. Письма на столе могут лежать неаккуратно и занимать много места. Более того, часть писем лежат в каких-то больших запечатанных конвертах. В этом случае чтобы положить на стол новое письмо надо сначала убрать самое старое с поверхности стола в ящик. Если письмо запечатано в большой красивый дизайнерский конверт, то его приходится оттуда для начала достать. Тут поможет несколько вещей. Во-первых, письма надо складывать поаккуратнее, чтобы большее их количество влезло на поверхность стола. Во-вторых, их стоит доставать из лишних упаковок, чтобы они занимали меньше места и чтоб сотрудникам, которые будут их читать, не требовалось делать это самостоятельно. В-третьих, стоит увеличить поверхность стола по возможности. При этом увеличение количества ящиков в столе не особо поможет. Главное чтобы ящики легко выдвигались. А лучше вообще избежать их использования.
P.S. Минута — очень длинный промежуток времени. Это уже территория high throughput.