Оптимизация веб-серверов для достижения высокой пропускной способности и низкой задержки
Простите, не удержался и перевел )))Источник Новость Несколько вольно, но все же
Это расширенная версия моего выступления в NginxConf 2017 6 сентября 2017 года. Являясь SRE в команде Dropbox Traffic, я отвечаю за нашу сеть Edge: ее надежность, производительность и эффективность. Dropbox edge network представляет собой прокси-уровень на основе nginx, предназначенный для обработки как транзакций с метаданными, чувствительных к задержкам, так и высокопроизводительных передач данных. В системе, которая обрабатывает десятки гигабит в секунду, одновременно обрабатывая десятки тысяч транзакций с чувствительностью к задержкам, оптимизация эффективности / производительности по всему стеку прокси, от драйверов и прерываний, через TCP / IP и ядро, до библиотеки и приложения настройка уровня.
Disclaimer
В этой статье мы обсудим множество способов настройки веб-серверов и прокси-серверов. Пожалуйста, не грузите их. Ради научного метода применяйте их один за другим, измеряйте их эффект и решайте, действительно ли они полезны в вашей среде.
Это не сообщение о производительности Linux, хотя я буду делать много ссылок на bcc-инструменты, eBPF и perf, это далеко не полный справочник по использованию инструментов профилирования производительности. Если вы хотите узнать больше о них, вы можете прочитать блог Брендана Грегга.
Это не про браузеры. Я буду касаться производительности на стороне клиента, когда я покрываю оптимизацию, связанную с задержкой, но только ненадолго. Если вы хотите узнать больше, вы должны прочитать «High Performance Browser Networking» Ильи Григорика.
И это про использование TLS best practices. Хотя я буду упоминать библиотеки TLS и их настройки несколько раз, вы и ваша команда безопасности должны оценивать эффективность и последствия для безопасности каждого из них. Вы можете использовать Qualys SSL Test, чтобы проверить свою конечную точку на основе текущего набора лучших практик, и если вы хотите узнать больше о TLS в целом, подумайте о подписке на бюллетень Fisty Duck Bulletproof TLS.
Structure of the post
Мы обсудим оптимизацию эффективности и производительности различных уровней системы. Начиная с самых низких уровней, таких как аппаратные средства и драйверы: эти настройки могут применяться практически для любого сервера с высокой нагрузкой. Затем мы перейдем к ядру linux и его стеку TCP / IP: это кнопки, которые вы хотите использовать в любом из ваших TCP-тяжелых ящиков. Наконец, мы обсудим настройки библиотеки и приложений, которые в основном применимы к веб-серверам в целом и nginx.
Для каждой потенциальной области оптимизации я попытаюсь дать некоторое представление о компрометациях с задержкой / пропускной способностью (если есть), руководства по мониторингу и, наконец, предложить настройки для разных рабочих нагрузок.
Hardware
CPU
Для хорошей асимметричной производительности RSA / EC вы ищете процессоры с поддержкой AVX2 (avx2 in / proc / cpuinfo) и, желательно, для аппаратов с большим числом арифметических аппаратных средств (bmi и adx). Для симметричных случаев вы должны искать AES-NI для шифров AES и AVX512 для ChaCha + Poly. Intel сравнивает производительность различных аппаратных поколений с OpenSSL 1.0.2, что иллюстрирует эффект этих аппаратных разгрузок.
Для чувствительных к задержкам прецедентов, таких как маршрутизация, выигрывает меньше узлов NUMA и отключается HT. Высокопроизводительные задачи улучшают работу с большим количеством ядер и получат выгоду от использования Hyper-Threading (если только они не связаны с кешем), и, как правило, они не будут заботиться о NUMA слишком много.
В частности, если вы идете по пути Intel, вы ищете, по крайней мере, Haswell / Broadwell и в идеале процессоры Skylake. Если вы собираетесь работать с AMD, EPYC имеет впечатляющую производительность.
NIC
Here you are looking for at least 10G, preferably even 25G. If you want to push more than that through a single server over TLS, the tuning described here will not be sufficient, and you may need to push TLS framing down to the kernel level (e.g. FreeBSD, Linux).
On the software side, you should look for open source drivers with active mailing lists and user communities. This will be very important if (but most likely, when) you’ll be debugging driver-related problems.
Memory
The rule of thumb here is that latency-sensitive tasks need faster memory, while throughput-sensitive tasks need more memory.
Hard Drive
It depends on your buffering/caching requirements, but if you are going to buffer or cache a lot you should go for flash-based storage. Some go as far as using a specialized flash-friendly filesystem (usually log-structured), but they do not always perform better than plain ext4/xfs.
Anyway just be careful to not burn through your flash because you forgot to turn enable TRIM, or update the firmware.
Operating systems: Low level
Firmware
You should keep your firmware up-to-date to avoid painful and lengthy troubleshooting sessions. Try to stay recent with CPU Microcode, Motherboard, NICs, and SSDs firmwares. That does not mean you should always run bleeding edge—the rule of thumb here is to run the second to the latest firmware, unless it has critical bugs fixed in the latest version, but not run too far behind.
Drivers
The update rules here are pretty much the same as for firmware. Try staying close to current. One caveat here is to try to decoupling kernel upgrades from driver updates if possible. For example you can pack your drivers with DKMS, or pre-compile drivers for all the kernel versions you use. That way when you update the kernel and something does not work as expected there is one less thing to troubleshoot.
CPU
Your best friend here is the kernel repo and tools that come with it. In Ubuntu/Debian you can install the linux-tools package, with handful of utils, but now we only use cpupower, turbostat, and x86_energy_perf_policy. To verify CPU-related optimizations you can stress-test your software with your favorite load-generating tool (for example, Yandex uses Yandex.Tank.) Here is a presentation from the last NginxConf from developers about nginx loadtesting best-practices: “NGINX Performance testing.”
cpupower
Using this tool is way easier than crawling /proc/. To see info about your processor and its frequency governor you should run:
