@Absm50336

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

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

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

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

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

Подскажите, что можно предпринять (если менять архитектуру, то на какую)? Пожалуйста, подробнее и более простым языком (для тупых).
  • Вопрос задан
  • 380 просмотров
Решения вопроса 4
все упирается в бд, на ум сразу пришло вынести эту часть в микросервис
Какой ещё микросервис? Микросервис, который делает что?

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

Я понимаю, что python и django не самые быстрые инструменты (мягко скажем)
Я вас уверяю, что проблема в вашей компетенции (мягко скажем), а не в инструментах. Есть достаточно проектов, написанных на Джанго, которые вывозят большие нагрузки.
Вы, в принципе, правильно сделали, что попытались поначалу закидать проблему железом - оно обычно дешевле, чем время разработчиков. Но параллельно надо и оптимизацией заниматься, и это требует системности, которой в вопросе не очень-то видно. Ну и компетенций разных - если тормозят алгоритмы - это одно, если конкретные SQL-запросы - это другое, если СУБД задыхается в принципе - это третье.
Ответ написан
petermzg
@petermzg
Самый лучший программист
1. Оптимизация SQL запросов.
2. Кеширование часто используемых данных.
3. Кеширование ответов на GET запросы.
Ответ написан
@Everything_is_bad
Запустил профилировщик, увидел, что все упирается в бд, на ум сразу пришло вынести эту часть в микросервис,
Начал правильно, но вывод сделал левый, по уму надо начать с тюнинга postgresql, оптимизировать SQL запросов (может у тебя там индексов не хватает или еще хуже, проблема N + 1), кешировании данных.
Ответ написан
Комментировать
@Drno
Если проблема в плохих SQL запросах - то переписывать их
Если проблема в медленности диска \ отсутсвии кеша(тот же redis) - значит разбираться с этим
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
mayton2019
@mayton2019
Bigdata Engineer
Когда начались тормоза, сразу добавил новый инстанс приложения, производительность практически удвоилась, но позже и второй инстанс начал задыхаться, добавил третий и производительность не увеличилась. Запустил профилировщик, увидел, что все упирается в бд, на ум сразу пришло вынести эту часть в микросервис, а основной монолит будет обращаться к этому микросервису, но опять же проблема, а что будет, когда и этот микросервис начнет задыхаться?

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

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
SpectrumData Екатеринбург
от 150 000 до 250 000 ₽
Гринатом Москва
от 150 000 ₽
DIGITAL SECTOR Краснодар
от 150 000 до 250 000 ₽
12 июл. 2024, в 16:31
20000 руб./за проект
12 июл. 2024, в 16:26
2000 руб./за проект
12 июл. 2024, в 15:54
300000 руб./за проект