Comments 15
После "посылает линуксу sikter" читать дальше не стал )
Такое ощущение, что статья записывалась продажником под устную диктовку инженера
Ощущение что инфа из первой части статьи оверпрайснутыми неквалами делалась, а потом пришёл нормальный инженер... Но очепятки и оговорки в тексте можно и поправить.
Если Вы про первоначальную реализацию доставки, то изначально была цель сделать рабочую штуку за минимальное время. Собственно поэтому взяли питон и быстренько навесили на него кронтаб. И только спустя время при попытке сэкономить на преемтиблах вылезли проблемы.
По поводу опечаток, исправили, спасибо.
Сильно удивлён отсутствию упоминаний io_uring, учитывая, что пошли в нативные биндинги и сисколлы в любом случае :/
Этот Kernel API задизайнен для высокопроизводительного I/O, уменьшения кол-ва копирований и переключений из ядерного пространства в юзерспейс, доступен в Linux Kernel с версии 5.1.
Или на момент проектирования он ещё не был в ядре и/или у вас старые версии ядра на серверах?
задача хорошо ложится на очереди: HTTP может быть serverless, масштабируется количество подписчиков.
Хорошая статья, но есть вопросы по бенчмарку.
Эти микробенчмарки проверяют разницу в производительности в write-heavy ворклоаде, но обычно production-code содержит микс дорогих и дешевых с точки зрения памяти операций и хорошей практикой микробенчмарков связанных с записью в подсистемы памяти является параметризация бенчмарков параметром backoff(как например в тестах автора JMH по стоимости записи в (https://shipilev.net/blog/2014/nanotrusting-nanotime/|volatile переменную)).
"Сжигая" некоторое количество времени перед записями в конце эксперимента можно будет построить график описывающий производительность и той, и той опции в зависимости от нагрузки на подсистему памяти и дать более реалистичную оценку.
Повышаем производительность файлового I/O в JVM на Linux