Ускорьте вашу программу на Python с параллелизмом

Начнем с не параллельной версии этой задачи. Обратите внимание, что для этой программы требуется модуль + запросы +. Вы должны выполнить + pip install request + перед его запуском, вероятно, используя virtualenv. Эта версия вообще не использует параллелизм:

Как видите, это довольно короткая программа. + download_site () + просто загружает содержимое из URL и печатает размер. Следует отметить одну небольшую вещь: мы используем http://docs.python-requests.org/en/master/user/advanced/#session-objects [+ Session +] объект из + запросы +.

Можно просто использовать + get () + из + запросы + напрямую, но создание объекта + Session + позволяет + запросам + выполнять некоторые хитрые сетевые трюки и реально ускорить процесс.

+ download_all_sites () + создает + Session + и затем просматривает список сайтов, загружая каждый из них по очереди. Наконец, он выводит, сколько времени занял этот процесс, чтобы вы могли с удовлетворением увидеть, насколько параллелизм помог нам в следующих примерах.

Диаграмма обработки для этой программы будет очень похожа на диаграмму ввода-вывода в последнем разделе.

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

Большая проблема здесь в том, что он относительно медленный по сравнению с другими решениями, которые мы предлагаем. Вот пример того, что окончательный вывод дал на моей машине:

Однако медлительность не всегда является большой проблемой. Если запущенная программа занимает всего 2 секунды с синхронной версией и запускается редко, вероятно, не стоит добавлять параллелизм. Вы можете остановиться здесь.

Что если ваша программа часто запускается? Что делать, если для запуска требуются часы? Давайте перейдем к параллелизму, переписав эту программу с помощью + threading +.

Как вы, наверное, догадались, написание многопоточной программы требует больше усилий. Вы можете быть удивлены тем, как мало дополнительных усилий требуется для простых случаев. Вот как выглядит та же программа с + threading +:

Когда вы добавляете + threading +, общая структура остается той же, и вам нужно всего лишь внести несколько изменений. + download_all_sites () + изменен с вызова функции один раз для каждого сайта на более сложную структуру.

В этой версии вы создаете + ThreadPoolExecutor +, что кажется сложной задачей. Давайте разберемся с этим: + ThreadPoolExecutor + = + Thread + + + Pool + + + Executor +.

Вы уже знаете о части + Thread +. Это просто ход мыслей, о которых мы упоминали ранее. В части + Pool + она начинает становиться интересной. Этот объект собирается создать пул потоков, каждый из которых может работать одновременно. Наконец, + Executor + - это часть, которая будет контролировать, как и когда будет работать каждый из потоков в пуле. Он выполнит запрос в пуле.

Полезно, что стандартная библиотека реализует + ThreadPoolExecutor + в качестве диспетчера контекста, поэтому вы можете использовать синтаксис + with + для управления созданием и освобождением пула + Threads +.

Если у вас есть + ThreadPoolExecutor +, вы можете использовать его удобный метод + .map () +. Этот метод запускает переданную функцию на каждом из сайтов в списке. Самое замечательное то, что он автоматически запускает их одновременно, используя пул потоков, которыми он управляет.

Те из вас, кто работает с другими языками или даже с Python 2, вероятно, задаются вопросом, где обычные объекты и функции, которые управляют деталями, к которым вы привыкли при работе с + threading +, такими вещами, как + Thread.start () + `, + Thread.join () + и + Queue + `.

Они все еще там, и вы можете использовать их, чтобы получить детальный контроль над тем, как работают ваши потоки. Но, начиная с Python 3.2, в стандартную библиотеку добавлена ​​абстракция более высокого уровня под названием + Executors +, которая управляет многими деталями, если вам не нужен этот детальный элемент управления.

Другое интересное изменение в нашем примере заключается в том, что каждый поток должен создать свой собственный объект + reports.Session () +. Когда вы просматриваете документацию по + query +, это не всегда легко сказать, но, читая this проблема, кажется довольно ясным, что вам нужно отдельный сеанс для каждого потока.

Это одна из интересных и сложных проблем с + threading +. Поскольку операционная система контролирует, когда ваша задача прерывается и запускается другая задача, любые данные, которые совместно используются потоками, должны быть защищены или поточно-ориентированы. К сожалению, + reports.Session () + не является поточно-ориентированным.

Существует несколько стратегий обеспечения доступа к данным для многопоточных приложений в зависимости от того, что это за данные и как вы их используете. Одним из них является использование поточно-ориентированных структур данных, таких как + Queue + из модуля Python + queue +.

Эти объекты используют низкоуровневые примитивы, такие как https://docs.python.org/2/library/threading.html#lock-objects [+ threading.Lock +], чтобы гарантировать, что только один поток может получить доступ к блоку кода или немного памяти в то же время. Вы используете эту стратегию косвенно через объект + ThreadPoolExecutor +.

Еще одна стратегия, используемая здесь - это локальное хранилище потоков + Threading.local () + создает объект, который выглядит как глобальный, но специфичен для каждого отдельного потока. В вашем примере это делается с помощью + threadLocal + и + get_session () +:

+ ThreadLocal + находится в модуле + threading +, чтобы конкретно решить эту проблему. Это выглядит немного странно, но вы хотите создать только один из этих объектов, а не один для каждого потока. Сам объект заботится о разделении доступа из разных потоков к разным данным.

Когда вызывается + get_session () +, + session +, который он ищет, специфичен для конкретного потока, в котором он выполняется. Таким образом, каждый поток создаст один сеанс в первый раз, когда он вызывает + get_session () +, а затем будет просто использовать этот сеанс при каждом последующем вызове на протяжении всей своей жизни.

Наконец, быстрое примечание о выборе количества потоков. Вы можете видеть, что пример кода использует 5 потоков. Не стесняйтесь поиграть с этим номером и посмотреть, как меняется общее время. Вы можете ожидать, что один поток будет загружен быстрее, но, по крайней мере, в моей системе это не так. Я нашел самые быстрые результаты где-то между 5 и 10 нитями. Если вы идете выше этого уровня, то дополнительные затраты на создание и уничтожение потоков стирают любую экономию времени.

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

Это быстро! Вот самый быстрый из моих тестов. Помните, что не одновременная версия заняла более 14 секунд:

Вот как выглядит временная диаграмма его выполнения:

Он использует несколько потоков для одновременной отправки нескольких открытых запросов на веб-сайты, что позволяет вашей программе перекрывать время ожидания и быстрее получать конечный результат! Yippee! Это была цель.

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

Потоки могут взаимодействовать способами, которые являются тонкими и трудными для обнаружения. Эти взаимодействия могут вызывать условия гонки, которые часто приводят к случайным, прерывистым ошибкам, которые может быть довольно трудно найти. Те из вас, кто не знаком с понятием условий гонки, возможно, захотят расширить и прочитать раздел ниже.

Прежде чем приступить к рассмотрению примера кода + asyncio +, давайте подробнее поговорим о том, как работает + asyncio +.

Это будет упрощенная версия + asycio +. Здесь есть много деталей, но они все еще передают идею о том, как это работает.

Общая концепция + asyncio + заключается в том, что один объект Python, называемый циклом событий, контролирует, как и когда запускается каждая задача. Цикл событий знает о каждой задаче и знает, в каком она состоянии. В действительности существует много состояний, в которых могут находиться задачи, но сейчас давайте представим упрощенный цикл обработки событий, в котором только два состояния.

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

Ваш упрощенный цикл обработки событий поддерживает два списка задач, по одному для каждого из этих состояний. Он выбирает одну из готовых задач и снова запускает ее. Эта задача находится под полным контролем, пока она совместно не вернет управление обратно в цикл обработки событий.

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

После того, как все задачи будут снова отсортированы в правильный список, цикл обработки событий выбирает следующую задачу для запуска, и процесс повторяется. Ваш упрощенный цикл обработки событий выбирает задачу, которая ожидала дольше всего, и запускает ее. Этот процесс повторяется до завершения цикла обработки событий.

Важным моментом + asyncio + является то, что задачи никогда не сдают контроль без намеренного выполнения. Они никогда не прерываются во время операции. Это позволяет нам легче распределять ресурсы в + asyncio +, чем в + threading +. Вам не нужно беспокоиться о том, чтобы сделать свой код поточно-ориентированным.

Это общий взгляд на то, что происходит с + asyncio +. Если вам нужна более подробная информация, this StackOverflow answer предоставит несколько полезных деталей, если вы хотите копать глубже.

Теперь давайте поговорим о двух новых ключевых словах, которые были добавлены в Python: + async + и + await +. В свете вышеприведенного обсуждения вы можете рассматривать + await + как магию, которая позволяет задаче передать управление обратно в цикл обработки событий. Когда ваш код ожидает вызова функции, это сигнал о том, что вызов, вероятно, будет чем-то, что займет некоторое время, и что задача должна отказаться от контроля.

Про + async + проще всего представить как флаг для Python, сообщающий, что функция, которая должна быть определена, использует + await +. В некоторых случаях это не совсем верно, например, asynchronous Generators, но это справедливо для многих случаев и дает вам простую модель, пока вы ' начинаем.

Единственным исключением из этого, которое вы увидите в следующем коде, является оператор + async with +, который создает менеджер контекста из объекта, который вы обычно ожидаете. Хотя семантика немного отличается, идея та же: пометить этот менеджер контекста как нечто, что может быть заменено.

Как я уверен, вы можете себе представить, что есть некоторая сложность в управлении взаимодействием между циклом событий и задачами. Для разработчиков, начинающих с + asyncio +, эти детали не важны, но вы должны помнить, что любая функция, которая вызывает + await +, должна быть помечена + async +. В противном случае вы получите синтаксическую ошибку.

Теперь, когда вы получили общее представление о том, что такое «+ asyncio », давайте пройдемся по версии « asyncio » примера кода и выясним, как он работает. Обратите внимание, что эта версия добавляет https://aiohttp.readthedocs.io/en/stable/[` aiohttp `]. Вы должны запустить ` pip install aiohttp +` перед запуском:

Эта версия немного сложнее, чем две предыдущие. Он имеет похожую структуру, но для настройки задач требуется немного больше, чем для создания + ThreadPoolExecutor +. Давайте начнем с верхней части примера.

+ download_site () + вверху практически идентична версии + threading +, за исключением ключевого слова + async + в строке определения функции и ключевых слов + async с +, когда вы на самом деле вызываете + session .get () + `. Позже вы поймете, почему `+ Session + может быть передан сюда вместо использования локального хранилища потока.

В + download_all_sites () + вы увидите самое большое изменение из примера + threading +.

Вы можете совместно использовать сеанс для всех задач, поэтому сеанс создается здесь как менеджер контекста. Задачи могут совместно использовать сеанс, поскольку все они выполняются в одном потоке. Невозможно, чтобы одна задача могла прервать другую, когда сеанс находится в плохом состоянии.

Внутри этого диспетчера контекста он создает список задач, используя + asyncio.ensure_future () +, который также заботится о их запуске. После того как все задачи созданы, эта функция использует + asyncio.gather () + для поддержания контекста сеанса до тех пор, пока все задачи не будут выполнены.

Код + threading + делает нечто похожее на это, но детали удобно обрабатываются в + ThreadPoolExecutor +. Там в настоящее время нет класса + AsyncioPoolExecutor +.

Однако здесь есть одно небольшое, но важное изменение, скрытое в деталях. Помните, как мы говорили о количестве создаваемых потоков? В примере + threading + не было очевидно, какое было оптимальное количество потоков.

Одним из замечательных преимуществ + asyncio + является то, что он масштабируется намного лучше, чем + threading +. Каждая задача занимает гораздо меньше ресурсов и меньше времени для создания, чем поток, поэтому создание и запуск большего количества из них работает хорошо. Этот пример просто создает отдельную задачу для каждого сайта для загрузки, которая работает довольно хорошо.

Наконец, природа + asyncio + означает, что вы должны запустить цикл обработки событий и сообщить ему, какие задачи нужно запустить. Раздел + main + внизу файла содержит код для + get_event_loop () + и затем + run_until_complete () +. Если ничего другого, они проделали отличную работу по названию этих функций.

Если вы обновились до Python 3.7, разработчики ядра Python упростили этот синтаксис для вас. Вместо + asyncio.get_event_loop (). Run_until_complete () + tongue-twister вы можете просто использовать + asyncio.run () +.

Это действительно быстро! В тестах на моей машине это была самая быстрая версия кода с хорошим запасом:

Диаграмма времени выполнения выглядит очень похоже на то, что происходит в примере + threading +. Просто запросы ввода-вывода выполняются одним потоком:

Отсутствие красивой оболочки, такой как + ThreadPoolExecutor +, делает этот код немного более сложным, чем пример + threading +. Это тот случай, когда вам нужно проделать небольшую дополнительную работу, чтобы получить гораздо лучшую производительность.

Также существует распространенный аргумент, что добавление + async + и + await + в соответствующих местах является дополнительным осложнением. В небольшой степени это правда. Обратная сторона этого аргумента заключается в том, что он заставляет вас задуматься о том, когда конкретная задача будет заменена, что может помочь вам создать лучший, более быстрый дизайн.

Проблема масштабирования также вырисовывается здесь. Запуск приведенного выше примера + threading + с потоком для каждого сайта заметно медленнее, чем запуск с несколькими потоками. Запуск примера + asyncio + с сотнями задач не замедлил его вообще.

На данный момент есть несколько проблем с + asyncio +. Вам нужны специальные асинхронные версии библиотек, чтобы получить полное преимущество + asycio +. Если бы вы просто использовали + запросы + для загрузки сайтов, это было бы намного медленнее, потому что + запросы + не предназначены для уведомления цикла событий о том, что он заблокирован. Эта проблема становится все меньше и меньше с течением времени, и все больше библиотек охватывают + asyncio +.

Другая, более тонкая проблема заключается в том, что все преимущества совместной многозадачности теряются, если одна из задач не взаимодействует. Незначительная ошибка в коде может привести к тому, что задача будет запущена и будет долго удерживать процессор, что приведет к истощению других задач, которые необходимо запустить. Цикл событий не может быть прерван, если задача не передает управление обратно к нему.

Имея это в виду, давайте перейдем к принципиально иному подходу к параллелизму, + multiprocessing +.

В отличие от предыдущих подходов, версия кода «+ multiprocessing +» в полной мере использует преимущества множества процессоров, которые есть у вашего крутого нового компьютера. Или, в моем случае, это мой неуклюжий старый ноутбук. Давайте начнем с кода:

Это намного короче, чем пример + asyncio + и на самом деле выглядит очень похоже на пример + threading +, но прежде чем мы углубимся в код, давайте кратко рассмотрим, что + multiprocessing + делает для вас.

До этого момента все примеры параллелизма в этой статье выполнялись только на одном процессоре или ядре вашего компьютера. Причины этого связаны с текущим дизайном CPython и тем, что называется Global Interpreter Lock, или GIL.

Эта статья не будет рассказывать о том, как и почему GIL. Сейчас достаточно знать, что синхронные версии + threading + и + asyncio + этого примера все работают на одном процессоре.

+ multiprocessing + в стандартной библиотеке был разработан для преодоления этого барьера и запуска вашего кода на нескольких процессорах. На высоком уровне это достигается путем создания нового экземпляра интерпретатора Python для запуска на каждом процессоре и последующей обработки части вашей программы для его запуска.

Как вы можете себе представить, создание отдельного интерпретатора Python не так быстро, как запуск нового потока в текущем интерпретаторе Python. Это тяжеловесная операция с некоторыми ограничениями и трудностями, но для правильной проблемы она может иметь огромное значение.

Код имеет несколько небольших изменений по сравнению с нашей синхронной версией. Первый находится в + download_all_sites () +. Вместо того, чтобы просто вызывать + download_site () + несколько раз, он создает объект + multiprocessing.Pool + и отображает + download_site + в итерируемые + sites +. Это должно выглядеть знакомо из примера + threading +.

Здесь происходит то, что + Pool + создает несколько отдельных процессов интерпретатора Python и каждый из них запускает указанную функцию для некоторых элементов итерируемого, который в нашем случае является списком сайтов. Связь между основным процессом и другими процессами обрабатывается модулем + multiprocessing +.

Строка, которая создает + Pool +, заслуживает вашего внимания. Во-первых, он не указывает, сколько процессов нужно создать в + Pool +, хотя это необязательный параметр. По умолчанию + multiprocessing.Pool () + будет определять количество процессоров в вашем компьютере и совпадать с ним. Это часто лучший ответ, и это в нашем случае.

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

Далее у нас есть часть этого вызова + initializer = set_global_session +. Помните, что каждый процесс в нашем + Pool + имеет свое собственное пространство памяти. Это означает, что они не могут делиться такими вещами, как объект + Session +. Вы не хотите создавать новый + Session + каждый раз, когда вызывается функция, вы хотите создать один для каждого процесса.

Функциональный параметр + initializer + построен именно для этого случая. Невозможно передать возвращаемое значение из + initializer + в функцию, вызываемую процессом + download_site () +, но вы можете инициализировать глобальную переменную + session + для хранения одного сеанса для каждого процесс. Поскольку каждый процесс имеет свое собственное пространство памяти, глобальный для каждого будет отличаться.

Это действительно все, что нужно сделать. Остальная часть кода очень похожа на то, что вы видели раньше.

Версия + multiprocessing + этого примера хороша тем, что ее относительно легко настроить и она требует небольшого дополнительного кода. Это также в полной мере использует мощность процессора в вашем компьютере. Диаграмма времени выполнения для этого кода выглядит следующим образом:

Эта версия примера требует дополнительной настройки, и глобальный объект + session + является странным. Вы должны потратить некоторое время на размышления о том, какие переменные будут доступны в каждом процессе.

Наконец, он явно медленнее, чем версии + asyncio + и + threading + в этом примере:

Это неудивительно, поскольку проблемы с вводом/выводом не являются причиной того, почему существует + multiprocessing +. Вы увидите больше, когда перейдете к следующему разделу и посмотрите на примеры, связанные с процессором.

Теперь давайте посмотрим на несовпадающую версию примера:

Этот код вызывает + cpu_bound () + 20 раз с различным большим числом каждый раз. Он делает все это в одном потоке в одном процессе на одном процессоре. Диаграмма времени выполнения выглядит следующим образом:

В отличие от примеров, связанных с вводом/выводом, примеры, связанные с ЦП, обычно достаточно согласованы по времени выполнения. Это занимает около 7,8 секунд на моей машине:

Очевидно, мы можем добиться большего успеха, чем это. Это все работает на одном процессоре без параллелизма. Давайте посмотрим, что мы можем сделать, чтобы сделать это лучше.

Как вы думаете, сколько переписать этот код с помощью + threading + или + asyncio + ускорит это?

Если вы ответили «Вовсе нет», дайте себе печенье. Если вы ответили: «Это замедлит это», дайте себе два печенья.

И вот почему: в приведенном выше примере с вводом/выводом большая часть общего времени была потрачена на ожидание медленных операций до завершения. + threading + и + asyncio + ускорили это, позволив вам перекрывать время ожидания вместо того, чтобы выполнять их последовательно.

Однако при проблемах, связанных с процессором, ждать не приходится. Процессор запускается так быстро, как только может, чтобы закончить проблему. В Python потоки и задачи выполняются на одном и том же процессоре в одном и том же процессе. Это означает, что один ЦП выполняет всю работу с непараллельным кодом, а также дополнительную работу по настройке потоков или задач. Это займет более 10 секунд:

Я написал + threading + версию этого кода и поместил его с другим примером кода в GitHub хранилище, чтобы вы могли иди проверь это сам. Однако пока не будем на это смотреть.

Теперь вы, наконец, достигли, где + multiprocessing + действительно сияет. В отличие от других библиотек параллелизма, + multiprocessing + явно предназначен для разделения тяжелых рабочих нагрузок ЦП между несколькими ЦП. Вот как выглядит временная диаграмма его выполнения:

Вот как выглядит код:

Мало что из этого кода пришлось менять по сравнению с не параллельной версией. Вам пришлось + импортировать multiprocessing + и затем просто перейти от циклического перебора чисел к созданию объекта + multiprocessing.Pool + и использованию его метода + .map () + для отправки отдельных чисел рабочим процессам по мере их появления. свободно.

Это было именно то, что вы сделали для кода + multiprocessing +, связанного с вводом/выводом, но здесь вам не нужно беспокоиться об объекте + Session +.

Как упомянуто выше, необязательный параметр + projects + для конструктора + multiprocessing.Pool () + заслуживает некоторого внимания. Вы можете указать, сколько объектов + Process + вы хотите создать и управлять в + Pool +. По умолчанию он определяет количество процессоров на вашем компьютере и создает процесс для каждого из них. Хотя это прекрасно работает для нашего простого примера, вам может потребоваться немного больше контроля в производственной среде.

Кроме того, как мы упоминали в первом разделе о + threading +, код + multiprocessing.Pool + построен на строительных блоках, таких как + Queue + и + Semaphore +, которые будут знакомы тем из вас, кто делал многопоточные и многопроцессорный код на других языках.

Версия + multiprocessing + этого примера хороша тем, что ее относительно легко настроить и она требует небольшого дополнительного кода. Это также в полной мере использует мощность процессора в вашем компьютере.

Эй, это именно то, что я сказал в прошлый раз, когда мы смотрели на "+ мультипроцессор +". Большая разница в том, что на этот раз это явно лучший вариант. На моей машине это займет 2,5 секунды:

Это намного лучше, чем мы видели с другими вариантами.

Есть некоторые недостатки использования + multiprocessing +. На самом деле они не отображаются в этом простом примере, но разделить вашу проблему так, чтобы каждый процессор мог работать независимо, иногда бывает сложно.

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