Весенняя загрузка холодного старта - PullRequest
Новая
       7

Весенняя загрузка холодного старта

0 голосов
/ 19 февраля 2019

У меня есть приложение с загрузочной пружиной, которое я запускаю внутри докеров в кластере openshift.В устойчивом состоянии существует N экземпляров приложения (скажем, N = 5), и запросы сбалансированы по нагрузке для этих N экземпляров.Все работает нормально, а время отклика низкое (~ 5 мс с общей пропускной способностью ~ 60 КБ).

Всякий раз, когда я добавляю новый экземпляр, время отклика кратковременно возрастает (до ~ 70 мс), а затем возвращается в нормальное состояние.

Могу ли я что-нибудь сделать, чтобы избежать такого холодного старта?Я пытался предварительно прогреть приложение, выполняя ~ 100 вызовов curl перед отправкой трафика, но это не помогло?

Нужен ли лучший скрипт прогрева с высоким уровнем параллелизма?Есть ли лучший способ справиться с этим?

Спасибо

Ответы [ 3 ]

0 голосов
/ 27 февраля 2019

Если ваше приложение исправно, когда вы отправляете ему запрос, но у вас все еще есть проблема с медленным ответом, попробуйте включить Многоуровневая компиляция 

-XX:CompileThreshold -XX:TieredCompilation

Обычно,ВМ использует интерпретатор для сбора информации о методах, которые передаются в компилятор.В многоуровневой схеме, в дополнение к интерпретатору, клиентский компилятор используется для генерации скомпилированных версий методов, которые собирают информацию о себе.

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

0 голосов
/ 28 февраля 2019

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

ApplicationStartup implements ApplicationListener<ApplicationReadyEvent>

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

@Component
public class ApplicationStartup implements ApplicationListener<ApplicationReadyEvent> {

    @Autowired
    YourService yourService;

    @Override
    public void onApplicationEvent(final ApplicationReadyEvent event) {

        System.out.println("ApplicationReadyEvent: application is up");
        try {
            // some code to call yourservice with property driven or constant inputs 
        } catch (Exception e) {
            e.printStackTrace();
        }
    }


}
0 голосов
/ 22 февраля 2019

Прежде всего, я бы попытался включить JIT-компиляцию и сравнить результаты.В Baeldung есть хорошая статья , в которой сравнивается производительность Graal со стандартными JIT-компиляторами C1 и C2 - возможно, вы захотите запустить некоторые тесты для своей рабочей нагрузки.В основном вам необходимо установить следующие параметры при запуске вашего Java-приложения:

-XX: + UnlockExperimentalVMOptions -XX: + EnableJVMCI -XX: + UseJVMCICompiler

Также,убедитесь, что вы настроили датчик готовности в OpenShift , используя URL проверки работоспособности привода Spring Boot ( / activator / health ).В противном случае ваш контейнер может получить трафик до того, как он будет готов к отправке.

Проверка готовности определяет, готов ли контейнер к обслуживанию запросов.Если проверка готовности завершает работу контейнера, контроллер конечных точек обеспечивает удаление IP-адреса контейнера из конечных точек всех служб.Датчик готовности может использоваться для сигнализации контроллеру конечных точек, что, даже если контейнер работает, он не должен получать трафик от прокси.Установите проверку готовности, настроив template.spec.containers.readinessprobe раздел конфигурации pod.

Наконец, ваши ответы также будут кэшироваться NGINX или другим обратным прокси-сервером.помогает.

...