Тестирование настраиваемой среды выполнения AWS для Swift
Настройка производительности в бессерверной среде - это ключ к быстрому реагированию серверной части и снижению вашего счета.
В этой статье будет проведено несколько тестов производительности, чтобы понять поведение AWS Lambda, написанного на Swift с использованием фреймворка Swift-Sprinter, и сравнить его с популярными языками и различными конфигурациями и параметрами.
Что такое лямбда?
Lambda - это ресурс AWS, обеспечивающий вычислительную мощность функции как услуги (FAAS). Он действует как строительный блок для более широкой категории услуг, известной как бессерверная.
Как и другие бессерверные блоки, он имеет следующие особенности:
- Это удалось.
- Это автомасштабирование.
- Это очень доступно.
- Это плата за использование.
В дополнение к обычным бессерверным функциям Lambda:
- Содержит код, необходимый для запуска.
- Управляется событиями.
- Поддерживает несколько языков на совместимом Linux.
- Он работает максимально долго.
Как работает AWS Lambda
Архитектура AWS Lambda, основанная на Firecracker на базе виртуальной машины EC2, была создана с возможностью автоматического масштабирования.
Холодный старт
При первом вызове Lambda новый рабочий экземпляр подготавливается путем копирования, инициализации и запуска кода.
Этот процесс называется холодным запуском и происходит каждый раз, когда среда Lambda добавляет новый рабочий экземпляр для масштабирования. Как только рабочий запускается, он получает событие, обрабатывает его, а затем выполняет запрос следующего события, остающегося в состоянии ожидания.
Горячий старт
После того, как воркер Lambda запущен, следующее выполнение - это чистая обработка предстоящего события, так как больше нет необходимости настраивать воркер.
В конце концов, по прошествии многих минут работник не получает никаких событий, он настраивается для уменьшения масштаба и освобождения неиспользуемых вычислительных ресурсов.
Вычислительная производительность
Производительность лямбда-вычислений зависит от используемого языка / среды выполнения, кода и выделенного объема памяти, который также определяет мощность центрального процессора.
Память - объем памяти, доступный функции во время выполнения. Выберите объем от 128 МБ до 3 008 МБ с шагом 64 МБ.
Lambda распределяет мощность процессора линейно пропорционально настроенному объему памяти. При размере 1792 МБ функция эквивалентна одному полному виртуальному ЦП (один виртуальный ЦП в секунду кредитов в секунду).
Чтобы выполнить оценку производительности в тех же условиях, все лямбда-выражения были настроены с 256 МБ памяти. Эта конфигурация дает Lambda 1/7 vCPU.
Предусмотренный параллелизм
Чтобы уменьшить количество холодных запусков, можно воспользоваться новой функцией, называемой подготовленный параллелизм, которая поддерживает постоянную теплоту некоторых лямбда-выражений.
Как оценить производительность
Лямбда-характеристики действительно важны, поскольку услуга продается по принципу плата за использование. Уменьшение времени выполнения и использования памяти на низком уровне помогает снизить текущие затраты на AWS Lambda.
Производительность языков в AWS Lambda определяется:
- Размер кода для выполнения.
- Объем используемой памяти.
- Скорость исполнения.
Выполнение простого «Hello, World» дает приблизительное представление о том, как язык выполняет очень простую задачу, и дает достаточно точную оценку времени выполнения AWS Lambda для языка.
Тяжелые вычислительные задачи могут кардинально изменить результаты теста «Hello, World», поскольку в этом случае тест будет иметь преимущество в эффективности языка при решении вычислительной сложности, а не во время выполнения AWS Lambda.
Для простоты в статье рассматривается только тест «Hello, World», оставляя читателю задачу проверки эффективности для других рабочих нагрузок.
Код и размер
Чтобы сравнить производительность со Swift, пример Hello World был реализован на разных языках.
В таблице выше представлены конфигурации, использованные для теста.
Swift против других языков
Первое, на что следует обратить внимание, это то, что AWS предоставляет среду выполнения для Ruby, Node.js, Python, Java, Go и .Net Core 2.1. Это дает этим языкам преимущество, поскольку у них нет накладных расходов по сравнению с настраиваемой средой выполнения с дополнительным кодом для загрузки.
Пример Hello World довольно прост, размер кода может быть совершенно другим, поскольку код добавляет больше зависимостей.
Код, используемый для Node.js, Python, Go, Ruby, Java, C # и Rust, тот же, что и в статье Бенчмаркинг среды выполнения AWS Lambda 2019 с добавлением примеров Swift .
Сборки и время выполнения Swift
Многие версии кода Hello World в Swift были добавлены для сравнения производительности:
- Быстрая среда выполнения с AsyncHTTPClient против libcurl.
- AsyncHTTPClient против AsyncHTTPClient с пулом соединений.
- Swift-Sprinter против Swift-Lambda-Runtime.
- Swift-код, созданный с использованием Ubuntu и Amazon Linux 2.
Нагрузка
Рабочая нагрузка подготовлена, как указано в статьях, указанных в конце.
Инструмент Артиллерия был использован для проверки лямбд. Шлюз API настроен для публикации лямбда-выражений как конечных точек HTTPS.
После вызова все метрики сохраняются в AWS CloudWatch.
Характеристики холодного старта
Характеристики холодного старта были собраны с помощью lumigo-CLI.
lumigo-cli analyze-lambda-cold-starts
- Наилучшую производительность при холодном запуске дают Rust (~ 30 мс) и Go (~ 75 мс), за которыми следуют Ruby (124 мс), Python (~ 127 мс) и Node.js (~ 128).
- Вторая группа включает Swift, созданный с помощью Amazon Linux 2 (~ 190 мс / ~ 219 мс) и C # .Net Core (~ 224 мс).
- Последняя группа содержит Swift, созданный с использованием Ubuntu (~ 329 мс / ~ 338 мс) и Java (~ 358 мс).
- Разница между Swift, созданным с помощью Amazon Linux 2, и Ubuntu составляет около 20 МБ размера пакета, что дает около 140 мс при холодном запуске.
Выступления с теплым стартом
Чтобы показать характеристики горячего старта, мы использовали настраиваемую панель управления в CloudWatch:
Наилучшую производительность в среднем дают C # .Net (~ 0,26 мс) и Go (~ 0,44 мс).
При производительности около 1 мс у нас есть Node.js (~ 1,06 мс), Java (~ 1,16 мс), Rust (~ 1,17 мс), Swift с NIO и пул соединений, созданный с помощью Ubuntu (~ 1,19 мс), Python (~ 1.34), Swift с NIO (~ 1,56 мс).
Сравнение быстрой сборки
- Среда выполнения Swift с AsyncHTTPClient NIO работает лучше, чем Swift с libcurl, с преимуществом ~ 0,65 мс.
- AsyncHTTPClient NIO с пулом соединений - лучший исполнитель с преимуществом ~ 0,30 мс в той же версии без пула и общей производительностью ~ 1,19 мс, сравнимой с Node.js, Java и Python.
- Swift-Sprinter работает немного лучше, чем Swift-Lambda-Runtime с разницей в ~ 0,20 мс.
- Код Swift, созданный с использованием Ubuntu по сравнению с Amazon Linux 2, работает с одинаковыми временами при горячем запуске.
Почему мне следует использовать Swift на AWS Lambda?
Swift был открыт в декабре 2015 года компанией Apple и вырос от мобильной разработки на iOS и Mac до серверных платформ Linux, таких как Ubuntu.
Любой, кто работает с iOS, знает, что язык безопасный, быстрый и выразительный. По сравнению с языками сценариев, такими как Node.js и Python, Swift повышает безопасность и производительность, избегая вредоносных побочных эффектов из-за неопределенного поведения языка и отсутствия проверки типов.
По сравнению с относительно новыми языками, такими как Go или Rust, Swift добавляет преимущество в виде большого сообщества мобильных разработчиков и энтузиастов.
Инвестиции Apple в Swift NIO и доступность Swift Package Manager стимулировали разработку многих серверных проектов и библиотек, включая HTTP-клиент, Postgres Client, Redis Client, AWS SDK Swift , MongoDB Swift Driver , gRPC Swift и другие.
Репозиторий Swift-Sprinter предоставляет настраиваемую среду выполнения AWS Lambda для Swift и основан на Ubuntu, чтобы гарантировать процесс сборки и четко определенный конвейер. Репозиторий содержит примеры использования и непрерывной интеграции.
Для всех, кто хочет поэкспериментировать, репозиторий Swift-Lambda-Runtime предоставляет версию Swift, построенную на базе Amazon Linux 2.
Доступность Swift в бессерверных фреймворках, таких как AWS, OpenWhisk и Azure, а также в традиционных API / веб-фреймворках, таких как Vapor, Kitura и Perfect на виртуальных машинах, Docker, Kubernetes и локальная HW открыла путь к полноценной разработке Swift.
В этой статье не рассматривается выбор конкретного поставщика облачных услуг, поскольку это будет зависеть от различных бизнес-причин, а не от технических соображений.
Преимущество использования Swift на AWS Lambda, а не контейнеров, эффективно, когда приложение, созданное с его помощью, не имеет постоянной рабочей нагрузки и требует масштабируемости при сохранении низких затрат. Бессерверные системы и контейнеры - не лучшая идея, и выбор необходимо оценивать для каждого варианта использования.
Соображения
Выбор среды выполнения AWS Lambda зависит не только от соображений производительности.
Всегда важно учитывать общую стоимость владения решением, принимая во внимание не только чистую стоимость бессерверного решения, но также надежность, ремонтопригодность, отказоустойчивость, возможность повторного использования, безопасность, поддержку платформы, доступность сторонних фреймворков, зрелость сообщества разработчиков. , инструменты разработки, лицензии, наличие навыков разработки и кривая обучения для конкретного варианта использования.
