Клиент Elasticsearch на AWS / Lambda / Java - время запуска клиента 2,5 секунды

Question

Мы используем AWS Lambda (Java) и клиент эластичного поиска для подключения к размещенному экземпляру эластичного поиска в AWS.Я столкнулся с долгим ожиданием по первому запросу около 2,5 секунд (поверх холодного старта).После этого это очень быстро.Я действительно не могу понять, откуда эта задержка, и я пытаюсь оптимизировать ее.между «5» и «6» видно, что задержка больше 2 секунд, которую я не могу на самом деле установить:

17:16:06.871INFO[PlacesPerformance] 1. Before testing elasticsearch client
17:16:06.932INFO[PlacesPerformance] 2. After getting elasticsearch client
17:16:06.933INFO[PlacesPerformance] 3. Before doing a elasticsearch query
17:16:06.935INFO[PlacesPerformance] 4
17:16:06.942INFO[PlacesPerformance] 5
17:16:09.179INFO[PlacesPerformance] 6
17:16:09.179INFO[PlacesPerformance] 7
17:16:09.181INFO[PlacesPerformance] 8
17:16:09.181INFO[PlacesPerformance] 9
17:16:09.183INFO[PlacesPerformance] 10
17:16:09.183INFO[PlacesPerformance] 11
17:16:09.362INFO[PlacesPerformance] 12
17:16:09.362INFO[PlacesPerformance] 13. After testing elasticsearch

Есть предложения о том, как это улучшить?

ОБНОВЛЕНИЕ:

Странно.Всякий раз, когда я запускаю код в лямбде, я испытываю задержку в 2,5 секунды при построении запроса (даже не выполняя его).Локально, это работает хорошо, хотя.Я попробовал следующее:

1.  Local against local elasticsearch. No delay.
2.  Local against AWS elasticsearch. No delay.
3.  Lambda with signing request. DELAY.
4.  Lambda without signing request. DELAY.
5.  Lambda with a 'match all' query. DELAY
6.  Lambda with a http address. DELAY.
7.  Lambda with a custom runtime. DELAY.
8.  Lambda with a custom runtime. DELAY.
9.  Lambda with standard Java 8 runtime. DELAY.

Answer 1

Проблема в том, что при первом запросе (реальный запрос, а не запрос на разогрев, поскольку запросы разогрева не проходят через код приложения, он не запускает загрузочные классы, которые используются в реальном пути запроса), JVM загружает (чтение,анализирует, проверяет и т. д.) связанные классы, инициализирует компоненты безопасности (шифры и т. д.) и выполняется квитирование TLS (требуется несколько RTT, в Java 9 и TLS 1.3 это следует уменьшить).

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

Answer 2

Лямбда-функции внутри VPC оказывают большое влияние на время запуска.Вы сказали, что ваш ES является размещенным экземпляром, поэтому я предполагаю, что он поддерживается VPC.

Даже если он не входит в VPC, холодные запуски Java обычно по своей природе длиннее времени выполнения, как Node или Python, потому чтоJVM должен быть запущен первым.Это в основном то, откуда берутся ваши 2,5 секунды.

ОК.Как решить проблему?

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

Теперь, если вы не знаете заранее, сколько параллельных лямбда-функций будет выполняться, у вас вроде нет выхода.Вы можете попытаться прогреть ваши функции Lambda заранее, но тогда вам нужно будет запустить 100 запросов одновременно, чтобы прогреть 100 различных контейнеров.

Пожалуйста, отметьте этот ответ , поскольку ярассмотрим параллельную модель лямбда-функций и то, как начинает работать холод / тепло.

Я с удовольствием отредактирую свой ответ, если у вас есть дополнительная информация или если я не достаточно ясен.