Эффективная многопоточность в python?

Question

[astrotrain]

Нужна многопоточность на скриптовом языке - пробовал pthreads для php 7, но не смотря на заявления разработчиков, все работает криво и беспричинно вылетает. Поэтому смотрю в сторону python (а есть ли альтернативы?), но то тут то там пишут что многопоточность в нем реализована так, что многопоточные приложения уступают обычным и что там есть какие-то проблемы с локами и синхронизацией. Так ли это? Опыт многопоточности в питоне небольшой - простые качалки файлов на с помощью thread, но там, я так понимаю есть более удобные и мощные инструменты. Собственно вопрос - че там с многопоточностью и какие модули лучше всего юзать? Зачади: парсинг веб-страниц и занесение данных в бд. Спасибо!

Answer 1

[Dimonchik]

asyncio решит все проблемы (если освоите, конечно )) )

если как в ПХП - смотрите, например,
toly.github.io/blog/2014/02/13/parallelism-in-one-line

но aiohttp для парсинга повеселее будет

кстати, Scrapy портировали на 3й Питон уже, но сами же говорят что сыроват

касаемо мультипоточности, вот пример кода:

if __name__ == '__main__':
    freeze_support()

    pool = Pool(processes=8)
    names = pool.imap_unordered(extract, glob.iglob(GLOBDIR), chunksize=1000)
    for name in names:
        extract(name)

можете поискать по кускам примеры применения

это винда, поэтому freeze_support(), в линухе еще проще
также (processes=8) не равно числу ядер (их 12), подбирается экспериментально от загруза проца, что в win что в lin

glob.iglob(GLOBDIR) читает список файлов по маске, поскольку это итератор, а для пула нужно конкретное конечное число, используется параметр chunksize=1000

функция extract(name) расжимает файл по адресу name, парсит его lxml и вносит поля в базу, такая комбинация грузит проц на 60-80%, когда в один поток - 9-12%

Comments

[astrotrain]

Асинхронный ввод-вывод это не совсем по теме, вопрос именно про мп.

[s0ci0pat]

astrotrain: У вас задачи парсинг веб-страниц и занесение данных в бд? Тогда asyncio решит все проблемы)

[astrotrain]

s0ci0pat: Ситуация такая, что у меня есть несколько функций на пхп, которые я запускаю каждую в отдельном потоке в классе, который наследуется вот Thread, хотелось бы точной такой подход применить в питоне.

[astrotrain]

s0ci0pat: Хотя сейчас почитал больше про asyncio, возможно тоже пригодится.

[astrotrain]

dimonchik2013, я понял, и спасибо за полезные линки.

Answer 2

[kazmiruk]

Что ж все так фигово читают вопрос. Все ответы выше никак не относятся к многопоточности. В питоне лучше вообще забыть что есть такое понятие "многопоточность", не ту технологию Вы выбираете для этого (хотя есть, конечно, pypy, но не в курсе на каком этапе там все. Также есть вариант с использованием процессов, но по мне это больше костыль). А в плане решения проблемы парсинга - да, можно заюзать асинхронность, но при этом будет использоваться один поток.

Comments

[astrotrain]

Ну я попробовал запустить на питоне скрипт по стандартной схеме (создание потоков, ожидание завершения и так по кругу пока не закончится информация на входе) - ну и скорость вполне себе, 100 линков за 60 секунд обошло. На рнр примерно так же было, но там почему-то скрипты валятся без видимой причины.

[Dimonchik]

питон мультикурл 2000 в минуту через прокси, ПХП тоже могет, но не большее 200-300

[astrotrain]

dimonchik2013: неплохо, но дело в том что там не только парсинг, а еще кое-какая работа с базой. Я не уверен что последовательная обработка будет такая же шустра как мп. А мультикурл он же на асинхронных сокетах работает или как вообще?

[astrotrain]

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

[kazmiruk]

astrotrain: с такой схемой Вам лучше использовать как раз таки асинхронность. В питоне есть куча всего под это дело (моя любимая либа - gevent, но вроде как стандарт уже asyncio). Но с многопоточностью это никак не связано. Многопточность в питоне хоть и создает несколько потоков, но переключение между ними происходит поочередно, т.е. как таковой параллельной работы нет. А это практически то же самое, что и в асинхронном подходе, только с накладными расходами на руление потоками. Ну и вообще вариант - по потоку на задачу - гиблый. Потоки довольно дорогие в плане ресурсов. Лучше использовать некий пулл если так хочется жонглировать потоками.

[Dimonchik]

astrotrain: да, сокеты, я обычно граблю им, а потом уже распаковываю и xpath на месте

[astrotrain]

kazmiruk: ну на сервере ресурсов много, приложение на рнр никогда даже до отметки 150 мб RAM не доходило, и процессорного времени ест чуть-чуть. Другое дело что на рнр это не очень хорошо работает.

Answer 3

[Dark Hole]

Да хоть Node.js

Answer 4

[sim3x]

Парсер сложно сделать параллельным
Паука - можно, но смысла нет

Общепризнанный паук на питоне scrapy.org

Comments

[astrotrain]

Каждый инстанс парсера работает со своей страницей - самое то.

[sim3x]

astrotrain: для такого использовать функицонал питона не обязательно

[astrotrain]

sim3x: а что можно использовать, если рнр тот же вылетает постоянно (а я только с этими ЯП в основном знаком)?

[sim3x]

astrotrain:
я б использовал скрапи и не мучался

Если делать велосипед, то bash parallel + скрипт на питоне с lxml

Читаем текстовик в баше, передаем его в parallel, parallel стартует питон скрипт

[astrotrain]

sim3x: но чем это лучше использования питоновских модулей для мп?

[sim3x]

astrotrain:
субьективно: проще, быстрее и економнее по памяти

[astrotrain]

sim3x: да памяти на сервере очень много, и такое простое приложение не должно много занимать. А почему быстрее, неужели многопоточность в питоне так реализована негодно?

[sim3x]

astrotrain:
беда не в питоне, беда в неумении его использовать

[astrotrain]

sim3x: так подскажите питоновский подход при котором такое мп приложение будет работать эффективно.

[sim3x]

astrotrain: scrapy.org

[astrotrain]

sim3x: это не подход же, а просто краулер.

[sim3x]

astrotrain:
он написан не на питоне?
он не облегчает паралельную работу?

[astrotrain]

sim3x: Это не подход, а узкоспециализированная тулза для парсинга, распараллелить работу с бд, файлами или с другими процессами он не может.

[sim3x]

astrotrain: потому для такого используют parallel

Answer 5

[Николай Карелин]

Когда разговор заходит о многопоточности, то нужно сразу отметить, какие типы задач интересуют.

Если речь идет о CPU-bound задачах, и надо нагрузить многоядерный процессор, то да GIL мешает (даже запрещает), и в Python надо компилировать расширение или использовать несколько процессов.

Если же дело в IO-bound - это практически все задачки связянные с сетью, включая веб, - то, как правило, блокирующая операция ожидания ответа от сети освобождает GIL и можно спокойно использовать многопоточность.

Другое дело, что сейчас многие советуют использовать именно асинхронные фреймворки (тот же asyncio), которые для сетевых задач дают гораздо лучшую производительность, чем нативные потоки (хотя, вроде, greenlets еще лучше).

Comments

[astrotrain]

Предполагалась работа не только с сетью но и з бд, файлами и прочим. А что значит компилировать расширение? Все питоновские модули многопоточности используют GIL?

[Николай Карелин]

Для начала: я говорю про референсную реализацию питона (aka CPython). Для нее GIL - это часть реализации (прошу прощения за тавтологию), и любой питоновский код может быть только однопоточным. Альтернативные реализации (в первую очередь, Jython) могут от этого не страдать.

Как правило, доступ к БД, файловой системе и всему остальному - это тоже написанная на Си функция, в которой GIL уже отпущен. Кстати, asyncio написан именно для операций ввода-вывода в целом, не только сеть, и для него уже есть куча соответсвующих дрйверов баз данных.

И последнее - CPython позволяет писать расширения - это функции на Си (или других языках), которые преврацаются в машинный код (например, DLL под Windows) и вызываются из кода на Питоне. В расширении GIL может быть отпущен.

Я недавно даже делал докдад на эту тему - милости прошу вот по этому адресу:
https://dev.by/lenta/space-blog/pycon-belarus-2016
(там же есть и про asyncio и семейство)

[astrotrain]

Спасибо, теперь в общем стало понятнее.

Answer 6

[Павел]

Здравствуйте, изнините за ответ вопросом: а Вам необходимо использовать скриптовые языки? Если да, то лушче подойдет python, там в коробке есть библиотека: multiprocessing (ну или как-то так, точно не помню, давно это было), собственно она опасная, вызов ее функций ограничивается главный циклом:

if __name__ == "__main__":
    вот тут вызываем

соственно это настоящая многопоточность, ибо она опходит GIL (Global Interpreter Lock)
вся загвоздка GIL в том, что в его понятии поток - есть очередь.
Например: у нас есть 3 потока, каджый выпоняет определенную функцию, для каждого свою; выполняется 1 поток, в нем выполняется, нарпимер, 100 операций, потом особая метка GIL переходит ко второму потоку, первый замораживается. Суть в том, что у кого метка GIL, тот и выполняется, остальные ждут метку GIL.
Если вам необходимо просто что-то сделать многопоточно, не зависимо от зяыка.
как вариант, можете посмотреть на C++, тут 3 варианта: MPI (есть билд для питона, можно запустить на кластере), PThread - ООП потоки, достаточно удобна в использовании, главное не залочить все потоки по кругу, в общем, внимательнее, OpenMP - няшечка компилятор сам все распаралелит, главное сказать какие циклы сделать паралельными, присутсвует в g++ и msvs2010+ (компилятор в Visual Studio).
Если вся проблема в том, чтобы запускать программу на любой платформе, то Вам могут подойти Qt и Mono

Comments

[astrotrain]

Да желательно скриптовые языки, потому что кроссплатформенность. Да вот про GIL я тоже читал, но на деле получается что мп скрипт все равно быстрее отрабатывает чем последовательный (не странно ли?)

[Павел]

Ну, вообще у питона самая развитая многопоточность, в руби ее как таковой нет, а если и есть то она нестабильная, руби такой руби. Про пхп7 я пока ничего не знаю, хочу дождаться LTS релиза, про PERL ничего сказать не могу

[Павел]

multiprocessing в целом плодит процессы, которые упровляются ос

[astrotrain]

Павел: ну в РНР она тоже нестабильная. Хотя автор pthreads говорит что версии 3.x уже нормально работает. Седьмой пхп уже доступен ведь и под него последний pthreads можно установить. Правда там какие-то тоже косяки, у меня пхп 7 х86 постоянно ошибки выдавал о нехватке ресурсов при старте более 10-20 тредов. В х64 можно запустить хоть 200. Но вот то что ни с того ни с сего все может упасть - это печально.

Answer 7

[artem78]

Я для многопоточного парсинга использую perl + модуль threads. С асинхронностью как-то не подружился да и для парсера разбор DOM (а не ожидание сети) отнимает основную часть времени.