> Jitsi небось активно JNI использует, как это сказывается на задержках?
Если имеется в виду Быстро ли делать JNI вызовы в натив, то да, быстро, оверхед приемлем. Если речь о том, что у нас какие-то операции в джаве, а у Jitsi в нативе, и может быстрее сходить в натив, то тут мы сравнений не проводили. А абстрактно это зависит от конкретных операций. Мы тоже не всё делаем в джаве. Например, сетевые вызовы идут через one-nio и linux сокеты, просто потому что в джаве не все есть. Например, нет sendmmsg. Для dtls шифрования мы используем Jitsi либу, которая использует openssl опять-таки через JNI.
> ZGC ещё не молодец?
Тоже молодец. На Java 17 и нашем размере хипа (10G) мы не увидели разницы против Shenandoah.
> Выбирали ли системный аллокатор?
При дефолтном аллокаторе в linux видели утечки памяти. Перешли на jemalloc. Когда-то пробовали tcmalloc, с ним не задалось. Также проверяли mimalloc, с ним футпринт вышел больше, чем с jemalloc.
На самом деле при 1-RTT handshake в Initial пакете Client Hello передается так же, как и при TLS over TCP. Можно убедиться в этом в Wireshark. А вот дальше почти все данные в QUIC пакетах будут шифрованными.
… фиксированный пул потоков, в каждом из котором свой цикл epoll, а слушающий сокет дублируется и может акцептиться в любом из потоков.
В приложении раздачи мы используем epoll и обертку над нативными сокетами one-nio. Принимает соединения один тред-акцептор, однако читают/пишут данные уже несколько тредов-селекторов. Число селекторов равно числу ядер на сервере, причем каждый селектор привязан к своему ядру через thread affinity.
… происходит попытка записать большой объем данных кусками в сокет без вызова epoll.
Селектор неблокирующе пишет в сокет только один раз, затем снова использует epoll.
Про устройство сервера раздачи и детали приложения также планируется статья.
Привет.
Сейчас нет, но есть планы попробовать. Для этого сперва нужно сделать поддержку в one-nio.
Привет.
Поясни, плз, как конкретно предлагаешь использовать Kafka?
Вообще на момент, когда мы реализовывали очередь (2013 год), Kafka у нас в проде не было.
Привет.
Графиками не подтвержу, но насколько помню, в пике где-то 15% цпу уходило на сборку.
Пробовали, но большой разницы не было. Поэтому по историческим причинам остались на Shenandoah (т.к. используем его в том числе и на OpenJDK 11).
> Jitsi небось активно JNI использует, как это сказывается на задержках?
Если имеется в виду Быстро ли делать JNI вызовы в натив, то да, быстро, оверхед приемлем. Если речь о том, что у нас какие-то операции в джаве, а у Jitsi в нативе, и может быстрее сходить в натив, то тут мы сравнений не проводили. А абстрактно это зависит от конкретных операций. Мы тоже не всё делаем в джаве. Например, сетевые вызовы идут через one-nio и linux сокеты, просто потому что в джаве не все есть. Например, нет sendmmsg. Для dtls шифрования мы используем Jitsi либу, которая использует openssl опять-таки через JNI.
> ZGC ещё не молодец?
Тоже молодец. На Java 17 и нашем размере хипа (10G) мы не увидели разницы против Shenandoah.
> Выбирали ли системный аллокатор?
При дефолтном аллокаторе в linux видели утечки памяти. Перешли на jemalloc. Когда-то пробовали tcmalloc, с ним не задалось. Также проверяли mimalloc, с ним футпринт вышел больше, чем с jemalloc.
На самом деле при 1-RTT handshake в Initial пакете Client Hello передается так же, как и при TLS over TCP. Можно убедиться в этом в Wireshark. А вот дальше почти все данные в QUIC пакетах будут шифрованными.
В приложении раздачи мы используем epoll и обертку над нативными сокетами one-nio. Принимает соединения один тред-акцептор, однако читают/пишут данные уже несколько тредов-селекторов. Число селекторов равно числу ядер на сервере, причем каждый селектор привязан к своему ядру через thread affinity.
Селектор неблокирующе пишет в сокет только один раз, затем снова использует epoll.
Про устройство сервера раздачи и детали приложения также планируется статья.