Sani c производительность веб-фреймворка - PullRequest
0 голосов
/ 13 февраля 2020

У меня вопрос к производительности sani c / asyncpg.

Во время тестирования продолжали происходить странные вещи (возможно, это из-за замысла).

Сначала позвольте мне объяснить процедуру тестирования. Это просто.

Я использую locust для максимально возможного pu sh сервера, устанавливая максимальное число пользователей.

Сценарий тестирования:

from locust import HttpLocust, TaskSet, task, between


class UserActions(TaskSet):
    @task(1)
    def test_point_1(self):
        self.client.get(
            '/json_1',
            headers={'Content-Type': 'application/json'}
        )

    @task(2)
    def test_point_2(self):
        self.client.get(
            '/json_2',
            headers={'Content-Type': 'application/json'}
        )


class ApplicationUser(HttpLocust):
    task_set = UserActions
    wait_time = between(0, 0)

Используется для протестируйте следующий код. Обратите внимание, что asyncpg вызывает функцию сна potgre sql для имитации нагрузки:

import asyncio
import uvloop
from asyncpg import create_pool
from sanic import Sanic, response
from sanic.log import logger
import aiotask_context as context

app = Sanic(__name__)

DATABASE = {
    'type': 'postgresql',
    'host': '127.0.0.1',
    'user': 'test_user',
    'port': '5432',
    'password': 'test_password',
    'database': 'test_database'
}

conn_uri = '{0}://{1}:{2}@{3}:{4}/{5}'.format(
            'postgres',
            DATABASE['user'], DATABASE['password'], DATABASE['host'],
            DATABASE['port'], DATABASE['database'])


@app.route("/json_1")
async def handler_json_1(request):
    async with request.app.pg.acquire() as connection:
        await connection.fetchrow('SELECT pg_sleep(0.85);')
    return response.json({"foo": "bar"})


@app.route("/json_2")
async def handler_json_2(request):
    async with request.app.pg.acquire() as connection:
        await connection.fetchrow('SELECT pg_sleep(0.2);')
    return response.json({"foo": "bar"})


@app.listener("before_server_start")
async def listener_before_server_start(*args, **kwargs):
    try:

        pg_pool = await create_pool(
            conn_uri, min_size=2, max_size=10,
            server_settings={'application_name': 'test_backend'})
        app.pg = pg_pool

    except Exception as bss_error:
        logger.error('before_server_start_test erred with :{}'.format(bss_error))
        app.pg = None


@app.listener("after_server_start")
async def listener_after_server_start(*args, **kwargs):
    # print("after_server_start")
    pass


@app.listener("before_server_stop")
async def listener_before_server_stop(*args, **kwargs):
    # print("before_server_stop")
    pass


@app.listener("after_server_stop")
async def listener_after_server_stop(*args, **kwargs):
    # print("after_server_stop")
    pass


if __name__ == '__main__':
    asyncio.set_event_loop(uvloop.new_event_loop())
    server = app.create_server(host="0.0.0.0", port=8282, return_asyncio_server=True)
    loop = asyncio.get_event_loop()
    loop.set_task_factory(context.task_factory)
    task = asyncio.ensure_future(server)
    try:
        loop.run_forever()
    except Exception as lerr:
        logger.error('Loop run error: {}'.format(lerr))
        loop.stop()

Проблема заключается в том, что после случайного количества времени сервер перестает отвечать (не возвращает 503 или любой другой код) для cca , 60 секунд Также процесс зависает (я вижу это с ps aux, а CTRL + C не может убить его.)

Это может быть проблематично c, потому что для одного его трудно обнаружить и трудно определить Скорость, с которой мы можем отправить запрос на сервер.

Может ли это быть проблемой с конфигурацией (sanic / asyncpg)?

Может ли установка nginx / sani c тайм-аут запроса быть единственной возможностью обойти эту проблему?

1 Ответ

0 голосов
/ 19 февраля 2020

Ваш пул aiopg ограничен 10 соединениями. Таким образом, максимум 10 запросов одновременно, каждый занимает 0,2 сек c, максимальная возможная нагрузка будет равна 1 сек c / 0,2 сек c * 10 размер пула = 50 RPS. После этого все входящие запросы будут просто ожидать подключения, и очередь запросов будет расти намного быстрее, чем ваша способность обслуживать, и ваш сервер перестанет отвечать на запросы.

...