Должны ли мы действительно повторно использовать глобальные переменные в лямбда-режиме AWS?

Question

Я цитирую этот очень сомнительный абзац из здесь относительно советов по производительности сервиса AWS-lambda.

По данным команды AWS:

Воспользуйтесь преимуществами повторного использования контекста исполнения для повышения производительности. вашей функции. Убедитесь, что любая внешняя конфигурация или зависимости, которые получает ваш код, сохраняются и на них локально после первоначального исполнения. Ограничить повторную инициализацию переменные / объекты при каждом вызове. Вместо этого используйте статический инициализация / конструктор, глобальные / статические переменные и синглтоны. Поддерживать и повторно использовать соединения (HTTP, базы данных и т. Д.), Которые были установлен во время предыдущего вызова

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

Мои вопросы:

1. что произойдет, если, например, истечет время ожидания соединения между одними лямбда-вызовами к другому? как среда выполнения AWS "знает", что не нужно повторно использовать это соединение?

2. что произойдет, если соединение буферизовано? что означает, что есть остатки от предыдущих вызовов?

3. действительно ли этот совет (повторное использование соединений через вызовы) действительно применим в реальной жизни? это кажется мне очень неприятным.

Answer 1

1. что произойдет, если, например, истечет время ожидания соединения между одними лямбда-вызовами к другому? как среда выполнения AWS «знает», нет ли для повторного использования это соединение?

2. что будет, если соединение буферизовано? что означает, что есть остатки от предыдущих вызовов?

Среда выполнения AWS вообще не «знает», как с этим справиться. Ваша лямбда-функция должна знать об этом, проверяя, является ли соединение все еще действительным, и обрабатывая ситуацию, если она больше не действительна.

3. действительно ли этот совет (повторное использование соединений через вызовы) действительно применим в реальной жизни? это кажется мне очень неприятным.

Учитывая реалии среды выполнения AWS Lambda, этот совет абсолютно действителен, если вы хотите уменьшить время холодного запуска для вызовов функций Lambda. Однако это, безусловно, может привести к проблемам с такими вещами, как подключение к реляционным базам данных, поэтому Amazon выпустила AWS Aurora Data API .

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