В связи со скорым стартом курса PHP-разработчик делимся с вами традиционным переводом материала. Приглашаем также посмотреть запись демо-урока Экосистема PHP.
Сегодня мы поговорим не про обычную аутентификацию электронной почты, дамы и господа. Мечта (веб-хостинга) 90-х все еще жива в Fraudmarc. Насладитесь скетчем Portlandia (с помощью VPN), а затем мы окунемся в истоки нашей серверной компании.
Перемещение битов по сети было нашим делом на протяжении десятилетий. Fraudmarc был создан на основе хостинговой компании с географически избыточными серверами с высоким временем безотказной работы. Это дает нам преимущество в круглосуточной эксплуатации глобальной инфраструктуры, которая обрабатывает важные данные для обмена сообщениями.
Этот сайт сделан на WordPress, и до недавнего времени мы с удовольствием полагались на самую лучшую и самую дорогую компанию провайдера WP. Но наш интерфейс wp-admin уже несколько месяцев страдает низкой производительностью, несмотря на все усилия их дружной команды технической поддержки. Если бы вы спросили меня, то я бы предположил, что они попали в классическую ловушку избыточной инфраструктуры, чтобы добиться более высокой прибыли во все более конкурентном пространстве хостинга WordPress. Я это понимаю, но, спасибо, не надо.
Не можем замедляться, не можем отвлекаться
Сотни предприятий делегируют управление политикой электронной почты Fraudmarc, чтобы они могли сосредоточиться на том, что могут делать только они. Они сосредоточены на максимальном заработке, а электронную почту делегируют нам.
Точно так же Fraudmarc отлично справляется с аутентификацией электронной почты (SPF, DKIM и DMARC), поэтому мы максимально сосредоточены на предоставлении этого сервиса нашим клиентам. Мы не можем отвлекаться на управление собственными серверами веб-хостинга. Мы используем множество других веб-инфраструктур, поэтому такой соблазн всегда присутствует, особенно когда наш старый провайдер WP хостинга начал сдавать позиции. И тут на сцену выходит SpinupWP, новая компания провайдер WP, которая позволяет нам предоставлять базовые сервера, пока они выполняют всю грязную работу с WP. Я с радостью продвигаю другие стартапы, которые делают сеть лучше, поэтому внизу этой статьи есть промо в размере 50 долларов для того, чтобы мотивировать вас попробовать их услуги.
В настоящее время нам полюбились ARM процессоры и мы используем их для многих инфраструктур API, БД и DNS в Fraudmarc, но вы должны быть осторожны, потому что они иногда намного медленнее, чем проверенные старые добрые x86 процессоры.
WordPress - единственное место, где Fraudmarc использует php, поэтому я решил поискать уже существующие бенчмарки php на arm64. PHP на Arm64 от Amazon AWS был хорошим началом, но упущен ряд важных моментов. Их пост был написан до релиза php 8 и ненарочно (?) пропустил однопоточные тесты, которые показывают, что arm64 на 50% медленнее, чем x86. В итоге вы читаете эту статью благодаря php на ARM, и я объясню вам почему.
Тестовая среда
Мы проведем бенчмарки с двумя официальными скриптами php: bench и micro bench. Наше тестирование будет проводиться на Ubuntu 20.04 на инстансах x86_64 c5.large и arm64 c6g.large. Каждый инстанс имеет два виртуальных ядра (vCPU) и 4 ГБ памяти. Php 7 устанавливается из репозитория Ubuntu по умолчанию, а php 8 из ondrej/php PPA. Вот конкретные версии, которые мы использовали:
PHP 7.4.3 (cli) (built: Oct 6 2020 15:47:56) ( NTS
)
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend
Technologies
with Zend OPcache v7.4.3, Copyright (c), by Zend
Technologies
PHP 8.0.3 (cli) (built: Mar 5 2021 07:54:13) ( NTS
)
Copyright (c) The PHP Group
Zend Engine v4.0.3, Copyright (c) Zend
Technologies
with Zend OPcache v8.0.3, Copyright (c), by Zend
Technologies
Подобно сжатию SPF, этот WP-сайт интенсивно использует кэширование в сотнях периферийных точек сети. Это означает, что запросы обслуживаются очень быстро из мест, близких к посетителям (или серверов приема почты в случае сжатия SPF), и продолжают работать, даже если исходный сервер выходит из строя. Серверы, которые мы тестируем, имеют два виртуальных ядра, которых достаточно для наших нужд, поскольку подавляющее большинство запросов обрабатываются периферийными узлами без необходимости выполнения какого-либо php на исходном сервере.
Мы протестируем серверы с помощью 14 параллельных бенчмарков, так как это должно соответствовать нагрузкам запрашиваемого оборудования на уровне 50%200%. Очевидно, что мы не можем использовать более 100% оборудования (два виртуальных ядра), но из-за природы интернет-трафика, склонной к пиковой нагрузке, в очереди постоянно возникает больше работы, чем может обработать сервер. В приведенной выше публикации о AWS бенчмарки производились только при 100% нагрузки запрашиваемого оборудования, что вряд ли когда-либо произойдет в реальной жизни. Мне интереснее понаблюдать за недонагруженными и перегруженными случаями, когда количество задач не совпадает идеально с количеством виртуальных ядер. В частности, я хочу увидеть штраф за многозадачность, когда ОС выполняет больше задач, чем у нее есть виртуальных ядер.
Первоначальные результаты
Среднее время выполнения (в секундах) за несколько запусков. 2x, 3x и 4x представляют количество одновременно запущенных бенчмарков.
Зеленый столбец показывает, что AWS не показывал: однопоточный php на 50% медленнее на инстансах с arm64 Graviton2. Ну дела. Но это еще не все.
Белый столбец показывает, что произошло, когда мы выполнили два бенчмарка одновременно. При полной нагрузке на оба виртуальных ядра инстанса arm был на 20% быстрее. Arm продолжал лидировать по мере увеличения количества параллельных бенчмарков.
Micro_bench.php показал похожую историю:
Давайте визуализируем эти результаты с теми же цветами столбцов.
Анализ
Я полагаю, что то, что мы наблюдаем здесь, это разница при одновременной многопоточности и полной нагрузке на ядра процессора. Поставщики десктопных ПК и серверные компании склонны отождествлять потоки и ядра. Типичное облачное виртуальное ядро (vCPU) это только поток, а не целое физическое ядро. Для сравнения представьте, что два потока используют одно ядро процессора. Примерно так это работает в средах x86. Сервера arm в этом отличаются. C6g работает на процессоре AWS Graviton2 arm64 без SMT, поэтому виртуальное ядро представляет собой реальное ядро ЦП.
Php на arm64 был на 50% медленнее, чем php на x86, если сравнивать физические ядра. Я ожидаю, что со временем это улучшится, поскольку AWS и другие разработчики продолжают выпускать для php патчи, связанные с arm. Php на arm оказался уже достаточно быстрым, чтобы это имело значение. Если сравнивать виртуальные ядра, то arm64 был быстрее и значительно дешевле, чем x86. По сравнению с x86 AWS взимает примерно на 20% меньше за виртуальное ядро на arm64. Их виртуальное ядро arm64 представляет собой полноценное физическое ядро, тогда как виртуальные ядра x86 представляют собой только потоки, совместно использующие одно физическое ядро процессора. Позвольте мне представить это вам визуально:
x86 (зеленая стрелка) был быстрее, чем arm (красная стрелка) с точки зрения физических ядер. В каждом из наших тестовых инстансов было по два виртуальных ядра, что подразумевает только одно физическое ядро на x86 и два ядра на arm. На минимальном уровне параллелизма одно ядро x86 запускает php быстрее всех.
Посмотрите вправо от красной стрелки, и вы заметите, где arm действительно раскрывается. Благодаря тому, что виртуальные ядра arm представляют собой полноценные ядра ЦП, инстанс с двумя виртуальными ядрами arm выполняли два одновременных бенчмарка на той же скорости.
arm64 быстрее при сравнении виртуальных ядер
Помните, что произошло, когда мы запустили две и более задач на эти два vCPU инстанса?
Зеленые стрелки показывают, насколько фактические ядра процессора на arm превосходят совместно используемые (многопоточные) ядра на x86.
Заключение
В одно предложение: этот сайт теперь работает на arm
На заведомо дорогой AWS виртуальные ядра ARM оказались на 20% дешевле, чем виртуальные ядра x86, не говоря о том, что требуется избыточное двукратное выделение виртуальных ядер, чтобы соответствовать количеству физических ядер эквивалентного инстанса на базе ARM. Есть что-то очень естественное в том, чтобы отделить выбор сервера от управления WP, особенно после нескольких месяцев низкой производительности от дорогостоящей WP-платформы. Замечательный плагин Query Monitor показывает, насколько быстро загружаются наши админские страницы.
Наш исходный сервер теперь выполняет WordPress (php) на выбранном НАМИ arm процессоре, но управляется настоящими экспертами по WP, поэтому мы по-прежнему сосредоточены на инновациях в электронной почте, таких как универсальный SPF решении нового поколения, которое преодолевает ограничения поиска DNS и другие нюансы записей SPF. Добавляя универсальную строку SPF в начало любой записи SPF, вы можете легко и практически мгновенно увеличить скорость доставки электронной почты.
Если вы находитесь в ~40% сети, которая работает на WordPress, вам следует обдумать переход на arm, потому что не так часто можно улучшить производительность при одновременном снижении затрат. Мы не нашли провайдеров WP хостинга, предоставляющих такие решения, но это только вопрос времени. Будут ли они экономить на наших конечных пользователях - остается только догадываться. Похоже, мы были первым клиентом SpinupWP, который использовал arm86 вместо x86_64, но Ubuntu имеет отличную поддержку arm, поэтому наша единственная проблема заключалась только в том, что изначально не работали бэкапы. Надеюсь, кто-то из SpinupWP увидит это и обновит свой сценарий установки, чтобы установить подходящую для архитектуры версию rclone.
А вот и реферальная ссылка на 50 долларов на счет SpinupWP на случай, если вы захотите поддержать другой небольшой стартап, который занимается важными делами.
Узнать подробнее о курсе PHP-разработчик.
Смотреть вебинар Экосистема PHP.
