Highload web server с большим количеством блокирующих потоки операций?
Кто в курсе, объясните, плз. Есть, например, unicorn или какой-либо еще сервер.
Как правило, при конфигурировании сервера, задается максимальное количество процессов и воркеров, т.о. мультитреадинг ложится целиком и полностью на веб-сервер. В случае, если при выполнении запроса возникнет блокирующая поток операция, она заблокирует поток целиком и он не будет доступен новым коннектам. Соответственно, если имеем лимит в 2 потока, и 2 пользователя нагрузили их полностью (что, конечно, дикость для большинства веб-приложений, но тем не менее), то новые пользователи не смогут получить ответы на свои запросы, пока хотя бы один из потоков не освободится. Это факт. Только что проверил.
В django есть встроенный сервер, который работает вообще без тормозов, он просто создает новый поток на каждый запрос - вообще ничего не блокирует, никаких ограничений и т.п. В этом случае мультитреадинг ложится целиком и полностью на совесть системы - где будет свободное процессорное время, на то ядро и полетит запрос (ну как я понимаю). Это тоже из эксперимента видно - делаем кучу запросов, они по очереди грузят разные ядра.
ВОПРОСЫ.
Почему нельзя такую схему использовать в продакшне? Почему все категорично против такого подхода и настоятельно рекомендуют задавать количество процессов и потоков вручную?
В конечном счете, если проц будет загружен, то и ресурсов для нового потока не будет. Даже если он все равно создастся, то просто операции в данном потоке будут ждать освобождения процессора - это не делает схему менее привлекательной, если бы распределением запросов по потокам занимался бы веб-сервер.
И в том и в другом случае, высокая нагрузка выльется в большое время ожидания, ну или, насколько я понимаю, если что-то лимитировать средствами веб-сервера, он может просто отвергать оверлоадные запросы, но и это тоже сомнительное преимущество, отталкиваясь от позиции, что лучше ответить пользователю поздно, чем вообще е ответить.
Поделитесь своими соображениями на эту тему или посоветуйте нормальную литературу/статьи, которые бы не начинались со слов "я не профессионал в этой теме, но..." или "статья не претендует ни на что, просто..."
У каждого инструмента своё назначение. Все мы слышали расхожие фразы про забивание гвоздей микроскопом и колку орехов молотом. Основная фишка Django - быстрая и простая разработка. Многопоточность же сама по себе не простая, а в Python и подавно. Поэтому Django однопоточный и синхронный. Всё в нём проектировалось с учётом последовательного выполнения и попытка применять параллельное приведёт к проблемам. Можно использовать его исполнение в многопроцесной среде, но это вопрос уже не к Django, а к среде исполнения. Например, к uWSGI. Почитать о динамическом выделении воркеров в uWSGI можно здесь. В самом Django же надо стараться делать так, чтобы вьюхи максимально быстро отдавали результат. Правильнее их проектировать так, чтобы длительные и блокирующиеся операции можно было переложить на Celery. Если же задача именно держать долго и упорно коннект с клиентом, то лучше посмотреть в сторону асинхронных фреймворков Tornado, aiohttp или Gevent.
А что вы понимаете под потоками ? объекты ОС или объекты внутреннего представления системы исполнения кода ?
если первое - то не оч хорошо создава/удалять
если второе - то это называется зеленые процессы (потоки). Тут уже как среда исполнения сама разрулит.
Например для Erlang можно создавать миллионы зеленых процессов и все будет летать как надо.
