Как увеличить производительность проекта на python?

Question

[Absm50336]

Здравствуйте!

Имеется postgresql->django->nginx интернет-магазин в виде монолита (работает на vds), который в основном занимается следующим: принимает запрос от клиента -> берет из бд нужные данные -> возвращает html с нужными данными.

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

Я понимаю, что python и django не самые быстрые инструменты (мягко скажем), но бюджета на переписывание на какой то более производительный яп пока нет.

Подскажите, что можно предпринять (если менять архитектуру, то на какую)? Пожалуйста, подробнее и более простым языком (для тупых).

Answer 1

[Алексей Уколов]

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

Какой ещё микросервис? Микросервис, который делает что?

В-нулевых, нужно конкретизировать что значит "упирается в БД". Тормозят какие-то конкретные запросы? СУБД не хватает ресурсов? Слишком медленный диск? Или, может, под "упирается в БД" вы понимаете всю бизнес-логику приложения, которую вы называете "берет из бд нужные данные" (и тогда становится понятно про микросервис)?
Во-первых, нужно вынести СУБД на отдельную машину, желательно на голое железо (если речь про реальный хайлоад, а не про кривой код и конфиги).
В-третьих, под это железо нужно СУБД корректно сконфигурировать.
В-четвёртых, нужно добавить кэширование.
В-пятых, нужно проверить алгоритмы и пофиксить узкие места (на последнем месте, потому что это самое трудоёмкое).

Я понимаю, что python и django не самые быстрые инструменты (мягко скажем)

Я вас уверяю, что проблема в вашей компетенции (мягко скажем), а не в инструментах. Есть достаточно проектов, написанных на Джанго, которые вывозят большие нагрузки.
Вы, в принципе, правильно сделали, что попытались поначалу закидать проблему железом - оно обычно дешевле, чем время разработчиков. Но параллельно надо и оптимизацией заниматься, и это требует системности, которой в вопросе не очень-то видно. Ну и компетенций разных - если тормозят алгоритмы - это одно, если конкретные SQL-запросы - это другое, если СУБД задыхается в принципе - это третье.

Comments

[Absm50336]

Я вас уверяю, что проблема в вашей компетенции (мягко скажем), а не в инструментах.

Поэтому и спрашиваю :)
Я понял, надо более конкретные вопросы. Спасибо за подробности!

[Алексей Уколов]

Absm50336, похвально, что вы адекватно реагируете на адекватную критику :)
Я переживал, что слишком жёстко сформулировал, но не смог придумать, как смягчить, не потеряв суть :)

[imageman]

Мне почему-то кажется, что после добавления кэширования нужно сразу посмотреть SQL запросы и посмотреть индексы в БД. Кстати, добавьте в вопрос какую СУБД используете, может гуру подскажут "серебряную" пулю :-)

[ThunderCat]

imageman, *перед
И в вопросе есть субд.

[imageman]

ThunderCat, Точно -- postgresql. И в самом начале. Тогда может стоит сказать какие шаги были сделаны для настройки? Хотя в вопросе много чего не сказано (к примеру параметры инстансов, размеры БД, характер запросов, соотношение записи к чтению и т.п.) - всего не скажешь в коротком вопросе...

Answer 2

[Петр]

1. Оптимизация SQL запросов.
2. Кеширование часто используемых данных.
3. Кеширование ответов на GET запросы.

Comments

[Алексей Уколов]

3. Кеширование ответов на GET запросы.

Наверное, речь тут конкретно про статику? Просто так огульно все GET-запросы никто не кэширует же.

[fenrir]

Алексей Уколов, предположу что подразумевался CQRS

[Алексей Уколов]

fenrir, я бы про CQRS в таком контексте не подумал :)

[Петр]

Алексей Уколов, Еще как кешируются, для примера запросы статистики по пользователю, которая редко меняется. Ту же самую корзину часто кешируют.

[Алексей Уколов]

Петр, а чем второй пункт тогда отличается от третьего?

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

Но это частности, которые я и имел в виду, когда говорил про "огульное кэширование" - да, можно проанализировать запросы и кэшировать (или не кэшировать) каждый так, как того требуют условия проекта. Но тогда это и есть "кэширование часто используемых данных". Я просто не понял, зачем отдельно GET-запросы выделять, кроме как кэшировать на уровне веб-сервера, а не приложения, и вот это уже явно плохая идея.

[Петр]

Алексей Уколов,
п.2 это кеширование внутренних данных приложения на базе которых делаются какие-либо частые проверки в коде. Напимер permissions/roles пользователя.
п.3 это уже сгенеренные данные ответа, без захода в бизнес логику приложения.

[Алексей Уколов]

п.3 это уже сгенеренные данные ответа, без захода в бизнес логику приложения.

Ну, то есть по сути - кэширование на уровне веб-сервера. Я бы сказал, что это почти всегда плохая идея, если речь идёт не про жёсткий-прежёсткий хайлоад.
Гибче всё же кэшировать внутри приложения: проще настроить, проще пофиксить, можно заложить логику инвалидации, сложнее ошибиться (кэширование той же корзины веб-сервером будет требовать разбора заголовков, например, если она сессионная). Да, это даёт дополнительный оверхэд, но он пренебрежительно мал, относительно плюсов-минусов.

[Петр]

Алексей Уколов, "Плохая идея" это не инженерный подход. )))
Для GET запросов и так подразумевается, что они могут кешироваться не только беком, но и другими прмежуточными прокси. В HTTP есть header "ETag" который как раз для таких случаев.

[Алексей Уколов]

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

Справедливое замечание.

В HTTP есть header "ETag" который как раз для таких случаев.

Но чтобы посчитать ETag для корзины, нужно всё равно на сервере её собрать и посчитать хэш. И в итоге получается экономия только на количестве передаваемых данных, а не на ресурсах сервера - проще и надёжнее выключить HTTP-кэширование совсем.
А вот для какого-нибудь списка стран, например, это самое то, да. Но таких справочников на проектах, как правило, не очень много. И кэшировать их "внутри" бизнес-логики не сильно "дороже", но сильно гибче (помним про необходимость инвалидации).

[Петр]

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

[Алексей Уколов]

Само собой, но я же написал - невозможно сгенерировать корректный актуальный ETag для корзины, не пройдя авторизацию, валидацию, агрегирование данных и SQL запросы. И даже шаблон, скорее всего, придётся собрать тоже (это ведь обычно JSON, а хэш для ETag проще всего получить из строки).
А в более простых сценариях справочников нет уже ни авторизации, ни валидации.

Я никогда не кэшировал данные на уровне веб-сервера, только статику. И не вижу причин начинать - экономию ресурсов это даёт такую мизерную, что эффект от неё заметен только на действительно огромной посещаемости.

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

Answer 3

[Everything_is_bad]

Запустил профилировщик, увидел, что все упирается в бд, на ум сразу пришло вынести эту часть в микросервис,

Начал правильно, но вывод сделал левый, по уму надо начать с тюнинга postgresql, оптимизировать SQL запросов (может у тебя там индексов не хватает или еще хуже, проблема N + 1), кешировании данных.

Answer 4

[Drno]

Если проблема в плохих SQL запросах - то переписывать их
Если проблема в медленности диска \ отсутсвии кеша(тот же redis) - значит разбираться с этим

Answer 5

[mayton2019]

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

Вопрос интересно звучит. Как будто - куда "соломки" положить чтоб мягче падать.

Пускай планом Б у тебя будет просто поднятие еще одной БД или нескольких БД с балансировкой.
Если 1 база не успевает отработать поток, по пол-потока или треть она успеет.

Попробуй мемоизировать результат ответа от БД. Положи в Redis. Это на тот случай если есть
горячие комбинации парамтеров запроса и есть вероятность что клиент их затребует несколько раз.

Подскажите, что можно предпринять (если менять архитектуру, то на какую)? Пожалуйста, подробнее и более простым языком (для тупых).

На данный момент ничего менять не надо. Т.к. непонятно в какую сторону тебе двигаться.
Однозначно тебе нужен хороший специалист по БД. Он должен уметь смотреть execution
plans и давать советы по тому какой сет индексов построить. Иногда помогает переход
в архитектуру Key-Value dbms (если это только не противоречит бизнесу). Поэтому я не скажу
что это совет. Это скорее мысль, о чем можно говорить с бизнесом.