- external-dns #689 (https://github.com/kubernetes-sigs/external-dns/issues/689)
- external-dns #1540 (https://github.com/kubernetes-sigs/external-dns/issues/1540)
- external-dns #5934 (https://github.com/kubernetes-sigs/external-dns/issues/5934)
- external-dns #6135 (https://github.com/kubernetes-sigs/external-dns/issues/6135)
как же классно
- external-dns #1540 (https://github.com/kubernetes-sigs/external-dns/issues/1540)
- external-dns #5934 (https://github.com/kubernetes-sigs/external-dns/issues/5934)
- external-dns #6135 (https://github.com/kubernetes-sigs/external-dns/issues/6135)
как же классно
GitHub
external-dns updates incomplete and infinite loop when ingress has several external addresses (cloudflare provider) · Issue #689…
I think this issue is the same as described in: https://kubernetes.slack.com/archives/C771MKDKQ/p1509029114000201 Even if there are no changes, and DNS looks correctly, I see and endless stream of ...
/ˈtæki.ɒn/
github.com/xdearboy/tachyon
написал по фану статический веб-сервер на C, чтобы проверить предел сокетов по HTTPS (TLS 1.3).
итог: стабильные 1 000 000+ RPS на обычной 28-ядерной виртуалке в proxmox, задержка 250 микросекунд и 20 МБ оперативки. в пике под плотным пайплайнингом переваривало около 5 млн RPS, пока провайдер не заблэкхоллил айпишник за подозрительный трафик.
за счёт чего так быстро:
• шифрование в ядре (kTLS): обычные серверы тратят кучу ресурсов на шифрование трафика внутри своего процесса. здесь программа только договаривается о соединении, а само шифрование отдаёт ядру линукса, которое делает это аппаратно и на лету
• zero-copy: готовый HTTP-ответ заранее лежит в памяти длинной лентой - сервер не тратит время на сборку строк, а отправляет данные сразу пачками
• привязка к ядрам процессора: каждый поток намертво сидит на своём ядре CPU, а сетевые пакеты прилетают сразу в нужный поток без очередей и переключений контекста
• ноль локов и мусора: нет очередей, мьютексов и тяжелых структур - только быстрые атомарные счетчики
github.com/xdearboy/tachyon
написал по фану статический веб-сервер на C, чтобы проверить предел сокетов по HTTPS (TLS 1.3).
итог: стабильные 1 000 000+ RPS на обычной 28-ядерной виртуалке в proxmox, задержка 250 микросекунд и 20 МБ оперативки. в пике под плотным пайплайнингом переваривало около 5 млн RPS, пока провайдер не заблэкхоллил айпишник за подозрительный трафик.
за счёт чего так быстро:
• шифрование в ядре (kTLS): обычные серверы тратят кучу ресурсов на шифрование трафика внутри своего процесса. здесь программа только договаривается о соединении, а само шифрование отдаёт ядру линукса, которое делает это аппаратно и на лету
• zero-copy: готовый HTTP-ответ заранее лежит в памяти длинной лентой - сервер не тратит время на сборку строк, а отправляет данные сразу пачками
• привязка к ядрам процессора: каждый поток намертво сидит на своём ядре CPU, а сетевые пакеты прилетают сразу в нужный поток без очередей и переключений контекста
• ноль локов и мусора: нет очередей, мьютексов и тяжелых структур - только быстрые атомарные счетчики
GitHub
GitHub - xdearboy/tachyon: High-throughput static HTTP/HTTPS engine written in C with Linux kTLS (1M+ HTTPS RPS)
High-throughput static HTTP/HTTPS engine written in C with Linux kTLS (1M+ HTTPS RPS) - xdearboy/tachyon
👍1🙏1
Forwarded from Баррель черной икры
Призывы к миру сегодня означают «поддержку нацистского режима», заявили в партии «Родина» на заседании Верховного суда. Это значит, что партия «Яблоко» за экстремизм должна быть снята с выборов, заявляется в иске. @banki_oil
👍1🌚1
Ждём решения суда
Please open Telegram to view this post
VIEW IN TELEGRAM