AWS Lambda: Кварки против обычной Java

На моей нынешней работе я использовал AWS Lambda с обычной Java 8, и, честно говоря, в первый раз это звучало для меня не слишком хорошо. Я имею в виду, не поймите меня неправильно, я в основном разработчик Java, но по предыдущему опыту я знаю, насколько медленным может быть запуск приложения Spring Boot, и тот факт, что бессерверные функции имеют то, что известно как “Холодный старт” , не имел слишком большого смысла для я.

Тем не менее, у них не было слишком много проблем с холодным запуском, потому что, во-первых, обычная Java (без фреймворка) быстрее, чем SpringBoot, а во-вторых, для тех сервисов, которые недоступны для холодного запуска, есть нечто, называемое “Прогрев”, которое раньше было просто CRON, который вызывал бы ваш лямбда-код. чтобы поддерживать его в рабочем состоянии и избегать холодных запусков, но теперь AWS выпустила новую функцию под названием “Выделенная емкость” , которая инициализирует запрошенное количество сред выполнения, чтобы они могли быть готовы отвечать на вызовы.

С другой стороны, не так давно я видел демонстрацию, проведенную сотрудником Red Hat их нового проекта Кварки . Это показало, насколько невероятно быстро можно запустить Java-приложение и насколько хорошо оно работает с Kubernetes, поскольку Quarks предназначался для того, чтобы сделать Java более дружественной к облаку.

Всего несколько дней назад мой мозг решил связать AWS Lambda с простой Java (как в моей текущей работе) и Quarks, и мне было интересно, каковы будут результаты с точки зрения холодного запуска, памяти и скорости для следующих запросов. Итак, это мой эксперимент, возможно, не самый точный с научной точки зрения, но я надеюсь, что он даст вам представление о производительности этих технологий с помощью AWS Lambda.

Эксперимент

Я разработал два простых проекта: один с Java 8 с клиентом DynamoDB по умолчанию, а другой с Quarks и клиентом Quarkus DynamoDB. Оба проекта просто распечатают полученный запрос, запросят существующий элемент DynamoDB и вернут его. В конце поста вы найдете репозитории, если захотите с ними поиграть (обратите внимание, что код некрасив, он был разработан только ради этого эксперимента). И это мои выводы:

Обычная Java 8

Код

public class HelloLambdaHandler implements RequestHandler {

    public DynamoGameScore handleRequest(GameScoreRequest input, Context context) {
        System.out.println(input);
        final GameScoreRepository repository = new GameScoreRepository();
        return repository.find(input.getUserId()).orElseThrow(NoSuchElementException::new);
    }
}

Бревна

Кварки Java 11

Код

@Named("test")
public class TestLambda implements RequestHandler {

    @Inject
    GameScoreRepository repository;

    @Override
    public DynamoGameScore handleRequest(final GameScoreRequest input, final Context context) {
        System.out.println(input);
        return repository.get(input.getUserId());
    }
}

Бревна

Итак, с точки зрения холодного запуска, мы можем оценить, что для первого запроса обычная Java 8 заняла почти 24800 мс до финиша, в то время как Кваркус сделал это менее чем за половину с 9000 мс .

Следующие запросы с функцией “hot” заняли у обычной Java 8 в среднем 484,78мс . В то время как для Quarkus это заняло в среднем 503,55 мс . Поскольку эти цифры относятся только к 3 запросам и цифры очень близки друг к другу, я бы осмелился сказать, что они, вероятно, сойдутся к одному и тому же числу при большей выборке. В любом случае, мы можем согласиться с тем, что после холодного запуска следующие запросы, похоже, длятся более или менее одинаково в обычной Java 8 или Quarkus.

Что касается памяти, справедливо отметить, что Quarkus ( 172 мб ) требовал больше памяти, чем обычная Java 8 (/| 137 Мб ). Но имейте в виду, что Quarks предоставляет нам функцию внедрения зависимостей (среди прочего), которую не предоставляет наш другой вариант.

Да, я знаю, вероятно, мне следует попробовать сделать 1 тыс. запросов и взять среднее значение, или, возможно, мой код несправедлив по отношению к одному из тестируемых объектов, я полностью открыт для предложений, но что я могу гарантировать, так это то, что я делал это 3 раза (разрушая всю инфраструктуру и создавая ее снова) и результаты были схожими.

Еще один момент, который следует принять во внимание, – это размер пакета, загружаемого в AWS. Мы можем оценить, что в этом случае Quarks тяжелее, чем обычная Java 8.

PD: Я знаю, что в Quarks есть функция, которая позволяет нам создавать собственное приложение, которое могло бы иметь более быстрый холодный запуск, но до сих пор мне не удалось заставить его работать с AWS Lambda. Когда я заставлю это сработать, я опубликую свои выводы.

Хранилища

Кварки Обычная Java 8

Оригинал: “https://dev.to/josemyduarte/aws-lambda-quarkus-vs-plain-java-25l9”