я переформулирую мысль так: неправильно настроенный uWSGI работает плохо) вывод не "не надо использовать uWSGI", вывод "надо уметь работать с инструментом"
я переформулирую мысль так: неправильно настроенный uWSGI работает плохо) вывод не "не надо использовать uWSGI", вывод "надо уметь работать с инструментом"
есть разница между настройками и глюками софта ювсги это именно второе, настраивать надо стабильный софт
Посмотрите, правильно ли я описываю общий процесс django? 1. Приходит пользовательский запрос и проходит через обработку middleware потом он передаётся в urls и там обрабатывается. 2. Из urls может напрямую передать запрос в views или в urls приложения. 3. Views - основная логика. views в зависимости от запроса берет или записывает данные с помощью файла models. 4. После получения результата обращения к models рендерит в файл шаблона.
то, о чём ты говоришь, вероятно, связано не с uWSGI, а со сборщиком мусора питона или что-нибудь из этой серии
нет, если тупо заменить на гуникорн, ничего не меняя, проблемы пропадают иными словами: я выберу чуть медленный но стабильный гуникорн, чем более быстрый но с кучей глюков ювсги
ну, чтобы говорить про кучу глюков - нужны какие-то логи с ошибками или что-то) учитывая, что у uWSGI, как и у Gunicorn'а воркеры перезапускаются, глюков быть не должно ни там, ни там)
Посмотрите, правильно ли я описываю общий процесс django? 1. Приходит пользовательский запрос и проходит через обработку middleware потом он передаётся в urls и там обрабатывается. 2. Из urls может напрямую передать запрос в views или в urls приложения. 3. Views - основная логика. views в зависимости от запроса берет или записывает данные с помощью файла models. 4. После получения результата обращения к models рендерит в файл шаблона.
Я правильно понял принцип?
почти, посмотри как обрабатываются большие запросы, поймешь целиком
ну, чтобы говорить про кучу глюков - нужны какие-то логи с ошибками или что-то) учитывая, что у uWSGI, как и у Gunicorn'а воркеры перезапускаются, глюков быть не должно ни там, ни там)