Медленное время ответа в моем API, приводящее к проблемам на сервере.

У нас есть сервер обратного прокси nginx (инстанс ec2). В последнее время мы сталкиваемся с проблемой медленной реакции, когда количество запросов в минуту увеличивается. Ниже приведена информация о моем приложении и сервере nginx:

1. Мы запускаем сервер приложений на базе Python Tornado как API-сервис.
2. Мы настроили nginx так, чтобы Tornado работал на 16 разных портах, и входящие запросы распределялись по этим портам. Например: предположим, что базовый конечный пункт API – “api.ecom.in”, если мы получаем запрос на “api.ecom.in”, то этот запрос назначается на один из работающих портов запущенного приложения Tornado.
3. Мы используем tornado-sqlalchemy для подключения к базе данных и пуллинга. Ниже приведен пример моего подключения к БД и сессии.

from tornado_sqlalchemy import SQLAlchemy
from contextlib import contextmanager

db = SQLAlchemy(url=DATABASE_URL, session_options={'expire_on_commit': False}, engine_options={'pool_size': 100,'max_overflow': 1400, 'echo': False, 'pool_recycle':1200 ,'connect_args': {'connect_timeout': 20}})

@contextmanager
def session_scope():
    session = None

    try:
        session = db.sessionmaker()

        yield session
    except Exception:
        if session:
            session.rollback()
        raise
    else:
        session.commit()
    finally:
        if session:
            # session.expunge_all()
            session.close()

4. Ниже приведен пример моего обработчика:

@jwtauth
class GetSeasonalProductHandler(BaseHandler):
    SUPPORTED_METHODS = ['GET']

    async def get(self):
        return self.send_response(data = await get_seasonal_product_service(self.request.query_arguments), status = 200)
    
    @classmethod
    def route_url(cls):
        return [
            (r'(?i)/api/v2/product_master/seasonal_product', cls, {})
        ]

5. Как вы можете видеть выше, есть функция с именем: “get_seasonal_product_service”, ниже приведен код функции:

async def get_seasonal_product_service(request_args):
    response_data = {}
    region_id = request_args['region_id'][0].decode('utf8')
    header_id = request_args['header_id'][0].decode('utf8') if 'header_id' in request_args else 1
    customer_id = request_args['customer_id'][0].decode('utf8')

    with session_scope() as session:
        seasonal_products = session.execute(
            "EXEC USP_ProductMasterSeasonal {region_id}, {header_id}, {customer_id}".format(
                region_id = region_id,
                header_id = header_id,
                customer_id = customer_id
            )
        ).fetchall()

    product_list = []
    for product in seasonal_products:
        product_list.append(dict(product))
    
    return product_list

Основная проблема: в последнее время, когда количество запросов в минуту увеличивается, время отклика моего API также начинает увеличиваться. Текущая величина запросов в минуту составляет около 12000 и более. В июле 2024 года мы смогли обрабатывать более 15000 запросов в минуту, и тогда все работало хорошо. Но с прошлой недели мы сталкиваемся с этой проблемой.

Мое наблюдение: я заметил, что мои SQL-запросы занимают слишком много времени. Я заметил, что удаление некоторых ненужных вызовов в моей служебной функции также немного помогло улучшить время отклика. Но, на мой взгляд, сокращение вызовов – это не решение, а временное решение. Мне нужно понять, нужно ли что-то оптимизировать на уровне сервера Python Tornado. Пожалуйста, помогите, если вы видите что-то не так в архитектуре Python. Я сам заметил, что tornado-sqlalchemy плохо оптимизирован для обработки асинхронных вызовов, и даже contextmanager работает синхронно. Но поскольку теперь моя вся архитектура зависит от этого синхронного session_scope(), у меня есть сомнения и трудности с его изменением на что-то асинхронное.

Что я пробовал до сих пор:

1. На данный момент я удалил все ненужные вызовы БД из своего API-сервиса.
2. Увеличил размер пула подключений. Добавил конфигурацию пула recycle = 1200, добавил timeout подключения к БД = 20
3. Увеличил количество работающих портов сервера приложений Tornado.
4. Мы планируем использовать Redis для кэширования некоторых ответов API, чтобы сократить обращения к БД (всё еще работаем над этим).