Нагрузочное тестирование API, реализованного на Django с DRF, выявило значительные различия в производительности в зависимости от применяемых методов кэширования. Изначально, без кэширования, приложение обрабатывало около 16 запросов в секунду (RPS) с высоким временем отклика и значительным процентом ошибок. Внедрение кэширования на уровне Django (с использованием Redis) увеличило производительность до 81 RPS, однако узким местом оставалась обработка запросов самим Django, что минимизировало выгоду от кэширования для простых запросов.
Кэширование на уровне Nginx показало более впечатляющие результаты. При базовой конфигурации и без прогрева кэша, RPS выросло до 363, но при этом также выявилась проблема с «прогревом кэша», так как gunicorn workers не успевали отдавать ответы для кэширования при высоком наплыве запросов. После прогрева кэша, производительность достигла 734 RPS, показав значительное улучшение, хотя по-прежнему оставался высокий процент ошибок, связанный с timeout-запросами.
Тестирование POST запросов, которые не могут быть закэшированы, показало максимальную производительность в 384 RPS с 55% ошибок. Здесь бутылочным горлышком выступал бэкенд и база данных. Эти результаты указывают на необходимость оптимизации как самой БД, так и Django.
Для дальнейшего повышения производительности рекомендуется исследовать возможность использования Granian вместо Gunicorn. Важным является также точная настройка параметров сервера, субд, Django и DRF. Стоит обратить внимание на возможность применения асинхронного ORM, де/сериализаторов и более продвинутых решений для кэширования, а также оптимизации Nginx и выбора более подходящих серверов.
Изображение носит иллюстративный характер
Кэширование на уровне Nginx показало более впечатляющие результаты. При базовой конфигурации и без прогрева кэша, RPS выросло до 363, но при этом также выявилась проблема с «прогревом кэша», так как gunicorn workers не успевали отдавать ответы для кэширования при высоком наплыве запросов. После прогрева кэша, производительность достигла 734 RPS, показав значительное улучшение, хотя по-прежнему оставался высокий процент ошибок, связанный с timeout-запросами.
Тестирование POST запросов, которые не могут быть закэшированы, показало максимальную производительность в 384 RPS с 55% ошибок. Здесь бутылочным горлышком выступал бэкенд и база данных. Эти результаты указывают на необходимость оптимизации как самой БД, так и Django.
Для дальнейшего повышения производительности рекомендуется исследовать возможность использования Granian вместо Gunicorn. Важным является также точная настройка параметров сервера, субд, Django и DRF. Стоит обратить внимание на возможность применения асинхронного ORM, де/сериализаторов и более продвинутых решений для кэширования, а также оптимизации Nginx и выбора более подходящих серверов.
