Python-сообщество

xneo
Аргумент про “падает только одна закладка” - не аргумент.

Поддержу. Нормально написанная программа может быть и в одном процессе при сохранении функционала. Разница как правильно заметил ZZZ только в том что треды нельзя масштабировать размещая их на физически разных машинах (я не говорю об экзотических библиотеках создающих виртуальную машину объединяющую в одном адресном пространстве расчетный кластер). Есть сумашедшая гипотеза. Такая архитектура позволяет Сожрать броузеру ресурсы нескольких машин в локальной сети. Запущеные броузеры могут тайно договориться и решать на разных машинах задачи индексации, распознования речи и изображения и т.п. Вот такая теория заговора :).

xneo
Моё личное мнение: GIL - это громадный костыль, который не даёт питону/пайтону оторваться от того же PHP.

• Костыль - да
  
• Оторваться - нет посмотрите рейтинги он оторвался.
  
• Надо срочно убирать GIL - не уверен. Вам не кажется что древняя концепция переключения тредов в хаотически распределенные моменты времени пережиток прошлого. Тех времен, когда было полно людей готовых написать бесконечный цикл, прервать который можно было только насильственно по будильнику переключая процессор в другой контекст. Во многом это вопрос языка на котором пишется программа, того предусмотрены в нем автоматически расставляемые точки синхронизации или аналогичные механизмы.
  Реализация нормальной поддержки сопрограмм и менеджеров задач с различными стратегиями может полностью исключить необходимость в использовании многопоточности. Собственно питон потихоньку идет по этому пути.
  

p.s.
Понятно что тут затрагиваются вопросы архитектуры ядра ОС или виртуальной машины. Но не хочется углубляться.

Отредактировано doza_and (Сен. 24, 2015 08:18:48)

JOHN_16
Какие из этого выводы можно сделать - что парсер HTML написан на Java

Не знаю, какие можно делать выводы, учитывая тот факт, что FireFox прекрасно работает без установленной джавы.

xneo, раз ты такой крутой, как варёное яйцо, то чего же ты задаёшь такие детские вопросы?
Отсюда я делаю вывод, что ты выше либо соврал, либо просто всю жизнь писал на каких них сях и никогда не разрабатывал распределённые приложения.

GIL в питоне есть. Костыль? Спорно.
Уйдёт ли он из CPython? Точно нет. Потому что это вообще никому не надо.

В общем, если тебе упёрся GIL, то не пиши на питоне. Просто потому, что это не твой язык. Ну или научись писать современные приложения.

P.S. Пиписькометрией заниматься не буду, уж извините.

P.S. Пиписькометрией заниматься не буду, уж извините.

Согласен, упустим.

С питоном я знаком мало. Объясните мне, какой я должен выбрать веб-фреймворк, чтобы при полной загрузке он нагрузил все 4 ядра CPU на 100%, как это будет выглядеть?

> GIL - это громадный костыль, который не даёт питону/пайтону оторваться от того же PHP.

На пыхе не писал, но насколько помню там потоков из коробки нет.
Если хочешь без GIL, то используй PyPy в нём GIL заменили на транзакции.

> Объясните мне, какой я должен выбрать веб-фреймворк, чтобы при полной загрузке он нагрузил все 4 ядра CPU на 100%, как это будет выглядеть?

Фреймворк не живёт в вакууме. Большую часть времени он простаивает в ожидании данных из СУБД, по этому процессор для него не столь критичен.

Да при чем тут вебфреймворк вообще? Это не задача веб-фреймворка, увеличивайте количество процессов в настройках uwsgi или чем вы создаете инстансы wsgi-приложения.

xneo, блин, вопрос реально некорректен. Загрузить все ядра процессора можно очень различными способами с ЛЮБЫМ, даже синхронным, web-фреймвоком. Достаточно базу данных положить на этот же сервер и всё время, которое питон будет ожидать ответа от базы, процессор будет загружен самой базой. Реально? Без проблем. Имеет ли практический смысл? Вряд ли.

У меня появилось стойкое ощущение, что ты не совсем в теме веба. Маленькая вводная…
Издревле, когда люди ещё использовали апач и CGI, каждый запрос порождал процесс. Это было нормальным. Эта идея видоизменилась, но неизменным осталась концепция, что каждый поток (процесс, нить… flow) обработки запроса пользователя, не должен иметь прямых пересечений с другими. Чем более он обособлен, тем лучше. В известных пределах, конечно. Это даёт возможность, распределять нагрузку не только между процессами, каждый из которых крутится на своём ядре, но и между серверами.
Конечно, в реальной жизни, всё не так просто, но это работает и делает нашу программёрскую жизнь значительно лучше.

Вернёмся к первому абзацу и вынесем БД (или любой “тяжёлый” внешний обработчик) за пределы application-сервера. В синхронном приложении можно запустить потоков, например, по числу ядер (читай про uWSGI и Gunicorn) и в один прекрасный момент все они будут ожидать ответа от базы. Нагрузка упадёт до нуля и использование сервера будет неэффективным. Можно ещё увеличить число процессов, но после определённого предела операционная система начнёт по этому поводу возмущаться и это плохо. Но для 99% всех web-приложений этого более чем хватит! Не надо оптимизировать то, что не требуется.

Пойдём дальше. Асинхронные фреймвоки. С приходом притона 3.4 и, ещё круче, 3.5, стало офигительно удобно писать асинхронные приложения, в которых в одном процессе пока один поток обработки запроса ждёт ответа, работает другой поток. Спасибо за это, кстати, топик стартеру (когда он писал эти статьи про GIL, asyncio ещё и в проекте не было). Так вот, тут можно загрузить все ядра процессора, числом процессов, равным числу ядер.
Да, не одним процессом. Но нет такой проблемы, которая помещает запустить их, например, восемь. Это всего один параметр в Gunicorn!

Но неизменным остаётся то, что обработчики запроса пользователя, не должны напрямую между собой общаться. В реальной жизни это просто не нужно. Всякие там чатики на веб-сокетах прекрасно живут на ZeroMQ. И это хорошо. Это ограничивает зоны ответственности и уменьшает общую связность приложения.

P.S. Про gevent, twisted и прочие извращенства я не упомянул специально. Сегодня они уже не нужны и со временем вымрут.

FishHook
Да при чем тут вебфреймворк вообще? Это не задача веб-фреймворка, увеличивайте количество процессов в настройках uwsgi или чем вы создаете инстансы wsgi-приложения.

Я хочу хранить общие/глобальные данные для всех соединений. Хранить их хочу не в БД с кучей говнокода. А именно в ОЗУ. Как мне это сделать, если у меня 10 процессов?

Отредактировано xneo (Сен. 24, 2015 14:20:15)

xneo
не в БД с кучей говнокода

это требует пояснений.

xneo
А именно в ОЗУ.

мм а БД в ОЗУ не подойдут? Из реляционных SQLite умеет так, из хранилищ всякие task manager'ы типа ZeroMQ и тп умеют именно это (т.е. без репликации на hhd) и большинство из них, как говорят люди пользовавшие, работают очень быстро.

Если вы прям так хотите обойти GIL, то для это воспользуйтесь распределением за счет процессов, делается это модулем multiprocessing, в доках и примеры передачи между процессами объектов.

Дежа вю… Буквально в прошлый четверг, в автобусе, по дороге на базу отдыха Иволга, один core developer celery рассказал там, что у него есть ровно такая же проблема. Правда он подошёл к ней немного иначе, но это не имеет особого значения… Так вот он рассказывал о сложностях shared memory между процессами, запущенными uwsgi. Ну мы хором его вразумили, чтобы он не делал херни и запилил отдельный сервис, обслуживающий эти данные. Он осознал свою ошибку и обещал больше так не делать.
Скорее всего, тебе подойдёт какой-нить redis, специально созданный для решения этой задачи.

Впрочем, я готов представить ситуацию когда действительно нужно именно shared memory, но за <вырезано детектером пиписькометрии> лет плактики, я такую ситуацию не встречал. Ни у себя, ни у других команд, коих я знаю в количестве <вырезано детектером пиписькометрии>. Отсюда делаю вывод, что скорее всего ты занимаешься преждевременной оптимизацией. Либо же просто не умеешь построить архитектуру современного проекта.