Я пишу это как ответ, а не комментарий, потому что, хотя он не может решить вашу ситуацию, он технически решает ваш вопрос. Кроме того, в комментарии просто недостаточно места для запроса всех необходимых разъяснений, чтобы перейти от одного к другому.
Я назначен для поддержки старого приложения Django. Это приложение используется для запуска синхронных рабочих Gunicorn. Однако становилось все медленнее. Недавно инженер внес изменения в использование асинхронных рабочих с оружием и gevent.
Метод развертывания в основном не имеет отношения к приложению Django, если только тот, кто его написал, не делал что-то, основанное на синхронной обработке запросов. По нескольким причинам я бы вернул метод развертывания в качестве первого шага.
- «Старое приложение Django» предполагает, что оно находится на версии, которая не поддерживается. Если это так, то он все равно не должен быть публичным, и в этом случае трафик почти наверняка незначителен.
- «Это становилось все медленнее» нуждается в объяснении. Если он каким-то образом набирал обороты со скоростью, которая заметно повлияла на его отзывчивость, означает, что - это симптом, с которого вам следует начать.
- Кто бы ни переключился с синхронизации на асинхронность, он должен представить свои аргументы и объяснить их должную осмотрительность, чтобы вы поняли, что они сделали, чтобы убедиться, что они поняли, что не собираются это ломать (и, если этого не хватает, вы, по крайней мере, можете знать, что вам не нужно искать).
На этой неделе система сильно пострадала, когда количество запросов HTTP увеличилось. Мы получили много ошибок: не удалось запустить новый поток в gevent.threadpool._add_thread. Представление Django с большинством обращений выполняет около 400 запросов SQL перед завершением и отображает сложный шаблон.
400 запросов на страницу указывают либо на на самом деле плохо написанный код, либо, что менее вероятно, на большое количество пользователей, просматривающих феноменально информативную страницу, которая не получает никакой пользы от какого-либо полезного вида кэширования. Вы упоминаете «улучшение запросов SQL» в комментарии, но ORM в Django довольно приличен в построении запросов, так что, надеюсь, вы просто говорите в целом; если тот, кто его построил, писал SQL вручную и передавал через ORM, это, безусловно, еще одна потенциальная проблема.
Было бы полезно, если бы вы могли предоставить информацию об объеме трафика, с которым система ранее хорошо справлялась, и объеме, который она сейчас душит. Также было бы полезно узнать о вашем развертывании; настройка автоматического масштабирования может смягчить это, хотя это также увеличит затраты, если вы перенастроите ее менее эффективным способом, так что это компромисс.
Может ли повышенное количество запросов и процессорного времени на визуализацию шаблона плохо играть с этим новым асинхронным рабочим? И если да, то как я могу объяснить это другим?
Если бы дело просто в том, что приложение перегружено запросами, асинхронное развертывание должно действительно помочь (или, по крайней мере, заставить базу данных считывать ваше узкое место, но это также крайне маловероятно, поскольку вы не читаете файл SQLite в дискета).
Пул соединений настроен так, чтобы не превышать лимит соединений postgres.
У вас совсем другая проблема, если вы достигаете предела подключения к БД. Я думаю, что это крайне маловероятно.