Что лучше выбрать, мультипоточность или мультипроцессинг?
Появилась задача переписать одну вещь в проекте, собственно решили делать на питоне.
Суть задачи:
>1000 активных процессов (ну либо потоков, надо выбрать), которые будут долбиться на другие сервера, забирать данные, парсить и тд и тп, но операции в принципе быстрые, правда эти процессы должны висеть круглосуточно и не падать, разве что ребутиться или завершаться по требованию.
Собсна уже почитал тучу холиваров на эту тему, а так как у самого основной язык не python, то прошу помощи у сообщества, помогите определиться что лучше: больше тысячи процессов запущенных одновременно, но с удобством их менеджмента, либо один процесс с тысячью потоками?
Алексей Уколов написали бы в ответ, я например с вами согласен) надо правда уточнить, что надо парсить, и есть ли нормальные библиотеки. Артём, что вам надо парсить?
Станислав Макаров: да я не спорю, более того, если бы я так не считал, то и комментить бы не стал.
Это просто вопрос семантики и поддержания ордунга: если автор задаст вопрос "На каких технологиях делать такую систему?", я ни секунды сомневаться не стану и напишу ответ, а не комментарий.
Маленький "фокус" питона, если захотите писать без фреймворка (scrapy и пр.), что один и тот же код создается и для многопоточной, и для многопроцессной задачи, отличаясь только используемым пакетом и классом (threading / multiprocrssing). Так что на этапе разработки можно пробовать оба варианта, и уже по ходу решить, что лучше.
Если вы не знакомы с Python, то для начала прочитайте про GIL - global interpreter lock.
Несколько лет назад выбор Python был бы оправдан. Но на сегодня я бы для решения такой задачи выбрал бы уже Go, а не Python.
Программировать на Go также просто как и на Python, а с параллельностью и конкурентностью у Go гораздо проще чем у Python.
Имхо, если язык не заточен на конкурентность - не Erlang, не Go и т.п. - то лучше запускать несколько экземпляров вашего приложения. По одному экземпляру на 1 физическое ядро.
Хотя 1000 потоков - не бог весь какая нагрузка.
Специально заморачиваться нужно только если вы хотите минимизировать оплату за хостинг или у вас эти задачи какие-то нагруженные.
У меня проект на Go прекрасно держит и 15 000 одновременных постоянных соединений, к примеру.
На слабом современном сервере (4 ядра, 4 гигабайта оперативки).
sim3x: Использование биндингов не дает возможности воспользоваться особенностями Go в полной мере. Запросто может оказаться, что pure Go реализация быстрее, чем биндинг. Но это нужно на конкретной задаче смотреть.
sim3x: чего ты тут оффтоп устраиваешь в комментариях? Задавай вопрос как простой смертный, а потом сам его удаляй, потому что "ведёт к дискуссии или спору" :)
Алексей Уколов: мне кажется, он задает эти вопросы к тому, что на питоне куда приятнее работать с html деревом. Библиотек куча и они отполированы временем.
О разнице между процессами и потоками - у процессов за изоляцию отвечает операционная система. Чтобы два процесса могли повзаимодействовать, нужно обращение к ОС, которое ведет к переключению контекста, что накладно.
У потоков таких расходов нет. Итого - потоки легче процессов. Но у них хуже с изоляцией - падение одного потока может уронить весь процесс.
Итого - если задачи в параллельной обработке между собой общаться не должны, первый выбор - процессы, так как изоляция лучше.
Если должны - выбор - потоки. И хорошая команда разработки. Не фигакпродакшн.
Ну я бы не запускал 1к. процессов. Я бы сделал процессов по количеству ядер процессора. К примеру унас 8 ядер на сервере то имеем 8 процессов и по 125 потоков в каждом.
