Каких-то существенных изменений в производительности мы не зафиксировали, при прежней конфигурации сервиса (количество под, количество процессов в поде) изменения по утилизации CPU на уровне статистической погрешности. Зато процессы стали перезапускаться в случае их смерти, что не дает нашей производительности деградировать.
Так сложилось исторически, в команде сервисы писали на Sanic. Проект довольно старый, а я пришел в него не так давно, поэтому определить истинные причины, боюсь, не получится)
Спасибо за такое доступное и в то же время информативное изложение информации, очень круто написано, и видно, что вложено много сил. Прочел с пользой и удовольствием)
Касаемо одного процесса на один контейнер: согласен, что это помогло бы в данной ситуации, но тогда бы нам пришлось увеличивать количество разворачиваемых подов приложения, и это негативно бы отразилось на общем времени развертки, что довольно критично в случаях, когда нужно быстро раскатить фикс, да и просто удлиняет релизный процесс. Мы хотели сохранить баланс между временем развертки и обрабатываемой нагрузкой.
Ну а хэлсчек мы тоже реализовали в первые же часы, и первое время жили на нем. Но проваленные хэлсчеки рестартят поду целиком, а мы бы не хотели просто так рестартить работающие процессы, поэтому целевым решением сохранили внедрение gunicorn'а, чтобы точечно переподнимать упавшие процессы.
Каких-то существенных изменений в производительности мы не зафиксировали, при прежней конфигурации сервиса (количество под, количество процессов в поде) изменения по утилизации CPU на уровне статистической погрешности. Зато процессы стали перезапускаться в случае их смерти, что не дает нашей производительности деградировать.
Так сложилось исторически, в команде сервисы писали на Sanic. Проект довольно старый, а я пришел в него не так давно, поэтому определить истинные причины, боюсь, не получится)
Спасибо за такое доступное и в то же время информативное изложение информации, очень круто написано, и видно, что вложено много сил. Прочел с пользой и удовольствием)
Касаемо одного процесса на один контейнер: согласен, что это помогло бы в данной ситуации, но тогда бы нам пришлось увеличивать количество разворачиваемых подов приложения, и это негативно бы отразилось на общем времени развертки, что довольно критично в случаях, когда нужно быстро раскатить фикс, да и просто удлиняет релизный процесс. Мы хотели сохранить баланс между временем развертки и обрабатываемой нагрузкой.
Ну а хэлсчек мы тоже реализовали в первые же часы, и первое время жили на нем. Но проваленные хэлсчеки рестартят поду целиком, а мы бы не хотели просто так рестартить работающие процессы, поэтому целевым решением сохранили внедрение gunicorn'а, чтобы точечно переподнимать упавшие процессы.
Спасибо!