Comments 11
ВАУ ОЧЕНЬ КРУТАЯ СТАТЬЯ !!!!!
в момент переноса было немного больно найти все места, где используются объекты
Request
Типизация не нужна, давайте писать на динамических языках, говорили они...
История с wsgi повторяется... может, и до pep на asgi договорятся.
Я так понимаю, что прод у вас в контейнерах. А почему бы тогда не запускать один процесс на контейнер и следить именно за ним? 12factor app предлагает делать именно так. Да и CFS будет понятнее работать.
Альтернативный вариант - переписать хелсчек таким образом, чтобы он проверял наличие процессов в поле.
Но это, конечно, как быстрое решение. Молодцы, что обновляетесь.
Касаемо одного процесса на один контейнер: согласен, что это помогло бы в данной ситуации, но тогда бы нам пришлось увеличивать количество разворачиваемых подов приложения, и это негативно бы отразилось на общем времени развертки, что довольно критично в случаях, когда нужно быстро раскатить фикс, да и просто удлиняет релизный процесс. Мы хотели сохранить баланс между временем развертки и обрабатываемой нагрузкой.
Ну а хэлсчек мы тоже реализовали в первые же часы, и первое время жили на нем. Но проваленные хэлсчеки рестартят поду целиком, а мы бы не хотели просто так рестартить работающие процессы, поэтому целевым решением сохранили внедрение gunicorn'а, чтобы точечно переподнимать упавшие процессы.
Спасибо большое. Жаль, что не слишком много пока статей по Sanic. Мне кажется, он заслуживает внимания
пользуясь случаем - порекламирую статью https://habr.com/ru/companies/domclick/articles/531254/ . Возможно она будет интересна
А что в итоге с производительностью? Я как-то в надежде на ускорение от перехода на python3.11 обновил версию sanic'а и обвязки и... получил ощутимое ухудшение производительности плюс непонятные покебания по памяти. Пришлось откатить всё назад, так как необходимости в обновлении версии не было. Но у нас было 100-200prs.
Каких-то существенных изменений в производительности мы не зафиксировали, при прежней конфигурации сервиса (количество под, количество процессов в поде) изменения по утилизации CPU на уровне статистической погрешности. Зато процессы стали перезапускаться в случае их смерти, что не дает нашей производительности деградировать.
Кстати, а почему изначально был выбран Sanic, а не тот же FastAPI?
Как мы версию Sanic’а повышали