AWS Лямбда против пустельги. NET Производительность ядра

Question

Я хочу разработать веб-API, используя. NET Ядро, которое должно обрабатывать большое количество одновременных запросов. Кроме того, WebAPI необходимо подключиться к базе данных. Веб-API будет внутренним и не будет отображаться в Inte rnet.

Я рассматриваю две возможности:

• Размещение ASP. NET Core приложение в Kestrel в одном или нескольких контейнерах / экземплярах EC2, с или без IIS.
• Бессерверное решение, использующее AWS Lambda

Я пытаюсь понять, какие соображения мне нужны знать, что это повлияет на производительность и стоимость каждого из этих решений.

• Я понимаю, что можно ожидать сервера Kestrel с приложением, использующим шаблоны asyn c / await для обработки большого количества одновременных запросов. Пул соединений с базой данных означает, что соединения с базой данных могут эффективно распределяться между запросами.

• В это сообщение на форуме AWS Lambda Я читал это:

Я понимаю этот вопрос больше в терминах «если AWS Лямбда-вызовы: response = Function (request) являются потокобезопасными».

Ответ положительный.

Это происходит по одной очень простой причине. AWS Лямбда не позволяет другому потоку вызывать один и тот же экземпляр лямбда до выхода из предыдущего потока. А поскольку несколько экземпляров лямбда одной и той же функции не совместно используют ресурсы, это тоже не проблема.

Я понял и интерпретировал это как значение:

• Каждый экземпляр лямбда может обрабатывать только один запрос за раз.
• Это означает большое количество экземпляров необходимы для обработки большого количества одновременных запросов.
• Каждый экземпляр лямбда-выражения будет иметь свой собственный пул подключений к базе данных (возможно, только с одним подключением).
• Таким образом, общее количество подключений к базе данных равно вероятно, будет выше, ограниченное пределом параллелизма на уровне лямбда-функции.
• Также по мере увеличения c трафика и создания новых экземпляров лямбда-выражения для ответа на запрос будет значительная задержка для некоторых запросов из-за время холодного старта каждого экземпляра лямбды.

Это понятно правильно?

Answer 1

Да, каждый экземпляр лямбда-выражения полностью изолирован и работает как один поток. Так что в вашем случае будет много подключений к базе данных.

Одна проблема с вашей архитектурой заключается в том, что вы пытаетесь смешать масштабируемый ресурс в этом случае лямбда с немасштабируемым ресурсом в этом случае реляционной базой данных. Я видел, как такие установки взорвались очень впечатляюще.

Итак, в вашем случае я бы либо go с несколькими c серверами, на которых запущен Kestrel, либо другой высокопроизводительный веб-сервер, либо заменил бы реляционная база данных с чем-то, что может плавно масштабироваться, например DynamoDB или, возможно, AWS Aurora