Спящее приложение Service Fabric

У меня есть небольшое приложение Service Fabric, которое я создаю, и с тех пор, как я преобразовал его в Service Fabric, меня раздражало медленное время запуска, и это происходит не только после выпуска, но и после 10-15 минут бездействия.

Я добавил проект, единственной целью которого является обращение к каждой службе и выполнение небольшого запроса БД каждые 10 секунд, думая, что это будет поддерживать работу приложения и ef. Это помогло мне получить тайм-ауты, и теперь первые запросы находятся в диапазоне 5-15 секунд. После некоторого прогрева запросы обычно находятся в диапазоне 300 мс, поэтому это довольно простые запросы, и между службами не так много связи (всего 4 службы).

После долгих поисков я нашел профилировщик, который, кажется, работает так, как большинству не нравится тот, что в Visual Studio. К сожалению, на самом деле он мало что сказал, за исключением того, что он много ждет потоков и что этого, похоже, нет в моем коде. Все мои внешние запросы используют await async. Кроме того, при выполнении запроса казалось, что информации не хватает...

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

В приложении есть все новейшие сервисные структуры, ядро ​​dotnet, ядро ​​ef, пакеты аналитики приложений. Все сервисы, кроме одного, проверяющего токены, не имеют состояния. И, конечно же, построен в режиме выпуска.

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


person user1842278    schedule 26.09.2017    source источник
comment
Вы развертываете это в кластере в Azure или просто испытываете это на своем локальном компьютере?   -  person Jesse Carter    schedule 26.09.2017
comment
У меня эта проблема как локально, так и при ее развертывании на кластере из 3 серверов, которого нет в лазури.   -  person user1842278    schedule 26.09.2017
comment
Предполагая, что ваш трафик сбалансирован по нагрузке... Запишите в журнал, на какой узел разрешается ваша служба. Может случиться так, что запрос 1 идет к узлу A (ответ 15 с), 2 к узлу B (ответ 15 с), 3 к узлу A (теперь ответ 300 мс), 4 к узлу C (ответ 15 с). Видишь, к чему я клоню?   -  person Mardoxx    schedule 27.09.2017


Ответы (2)


Аналогичная проблема возникает и у нас, однако мы используем контейнер DI, и до первого вызова нашей службы все зависимости не разрешаются, и для создания этих экземпляров требуется время. Например синглтон класса. Другим был контекст EF DB. Чтобы преодолеть это, у нас есть процесс, чтобы сначала «подогреть» сервисы.

надеюсь, это поможет

person duongthaiha    schedule 26.09.2017
comment
Это не объясняет, почему его приложения засыпают через несколько минут! - person Mardoxx; 27.09.2017

Это может быть выстрелом в темноту: ваши службы обмениваются данными, используя параметры удаленного взаимодействия Service Fabric или используя HTTP? В случае HTTP может ли HttpSys/Kestrel вызывать спящий режим и время прогрева?

Что касается ваших медленных ответов (300 мс), которые кажутся немного странными, у нас есть несколько служб без сохранения состояния (с использованием HTTP и Kestrel) с EF сзади, и время отклика составляет менее 50 мс).

person Esben Bach    schedule 05.10.2017