Считаем котов: async с лимитами

В прошлый раз мы асинхронно обработали 10 тысяч видео за одну секунду:

processors = [process(url) for url in reader("data/urls.txt")]
for task in asyncio.as_completed(processors):
  video = await task

Processed 10000 videos, took 1.25 seconds

Ну разве не успех? В теории — да, на практике — не особо.

Во-первых, в списке processors лежит 10 тысяч корутин еще до того, как мы начали обработку. Конечно, 10 тысяч — не слишком много, но что делать, если их там будет 10 миллионов?

Во-вторых (и это намного хуже), asyncio.as_completed() разом выстрелит 10 тысяч запросов к кластеру обработки видео.

Скорее всего, большую часть запросов кластер отобьет с ошибкой типа «Too Many Requests», на чем все и закончится. Либо попытается переварить эти 10 тысяч видео разом и уйдет в 100% загрузку (а то и вовсе упадет), за что нам немедленно настучат по голове админы.

На практике никто не даст обработать прям все данные за один раз. Вместо этого нам скажут: «можете делать не более 16 одновременных запросов к кластеру». Но как реализовать это ограничение? asyncio.as_completed() так не умеет.

Придется сделать обертку, которая гарантирует, что одновременно запущены не более N задач:

max_workers = 16
processors = [process(url) for url in reader("data/urls.txt")]
for task in as_completed(max_workers, processors):
  video = await task

Все, что изменилась — наша реализация as_completed() вместо стандартной. Детали можете посмотреть в песочнице, но основная мысль — использовать семафор. Это объект, который ведет счетчик использованных ресурсов (запущенных задач в нашем случае), и не дает использовать более N ресурсов одновременно.

Конечно, обработка теперь занимает не одну секунду:

Processed 10 videos, took 1.00 seconds
Processed 100 videos, took 6.62 seconds
Processed 1000 videos, took 59.91 seconds

Но все еще в 16 раз быстрее, чем обрабатывать видео последовательно.

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

песочница

#stdlib

Считаем котов: потоки

async — сравнительно новый «родной» для питона способ многозадачности. Вычисления выполняются в одном потоке, но можно насоздавать кучу легковесных задач. В каждый момент времени выполняется одна задача, а прочие ожидают I/O (ответа от кластера в нашем случае). Если I/O много, то работает весьма шустро.

Если по каким-то причинам async вам недоступен, можно воспользоваться старым проверенным способом — родными потоками операционной системы (threads).

Здесь мы приходим к задаче «читатель-обработчик-писатель», которая в разных вариациях постоянно встречается в реальной жизни. Читатель, обработчик и писатель — независимые акторы, каждый из которых делает свое дело. Между собой эти ребята общаются через очереди:

reader → in_queue → processor → out_queue → writer

Получается конвейер из трех шагов. Реализуем их:

def read_step(filename, in_queue):
  for url in reader(filename):
    in_queue.put(url)

def process_step(in_queue, out_queue):
  while True:
    url = in_queue.get()
    video = process(url)
    out_queue.put(video)

def write_step(out_queue):
  while True:
    video = out_queue.get(timeout=1)
    w.send(video)

Запустим в отдельных потоках одного читателя, одного писателя и N обработчиков. И подружим их между собой с помощью очередей:

filename = "data/urls.txt"
in_queue = Queue(1024)
out_queue = Queue(1024)
max_processors = 16

with ThreadPoolExecutor(2 + max_processors) as executor:
  executor.submit(read_step, filename, in_queue)
  for _ in range(max_processors):
    executor.submit(process_step, in_queue, out_queue)
  executor.submit(write_step, out_queue)

Реальный код сложнее, потому нужно отслеживать, когда все акторы закончат работу — иначе программа никогда не завершится. Это можно сделать простым «грязным» способом через таймауты или сложным, но точным — через примитивы синхронизации. В песочнице вариант с таймаутами.

Время обработки примерно такое же, как у варианта с async:

Processed 10 videos, took 1.00 seconds
Processed 100 videos, took 6.63 seconds
Processed 1000 videos, took 60.04 seconds

Замечу, что потоки в Python совсем не те, что в Java или C#. Из-за глобальной блокировки интерпретатора (GIL) в каждый момент времени может выполняться только один поток. Так что для I/O задач потоки подходят (как и async), а вот для CPU задач — совсем нет.

песочница

#stdlib

Да, кстати. Если по всей этой теме с многозадачностью что-то непонятно — можно уточнить в комментариях. Я отвечу там же или в отдельной заметке.

Если у вас лапки и совсем ничего не понятно, не переживайте — скоро переключимся на более лайтовые темы ツ

Считаем котов: процессы

Многозадачность на async и потоках сработала, потому что наши акторы в основном ждут ответа от внешнего кластера. Python (в случае с async) или ОС (в случае с потоками) постоянно «жонглируют» обработчиками, а на CPU в каждый момент выполняется только один.

Но что делать, если обработчикам нужно 100% времени CPU? Например, если они что-то вычислают, выполняют алгоритмы или работают со структурами данных? И потоки, и async здесь бессильны — от многозадачности не останется и следа.

Единственный рабочий вариант с CPU-bound задачами — использовать честные процессы операционной системы. Благо на Python с процессами можно работать почти так же, как с потоками.

Наши читатель (read_step), писатель (write_step) и обработчик (process_step) остаются прежними. Меняем пул потоков на пул процессов — и готово:

filename = "data/urls.txt"
manager = Manager()
in_queue = manager.Queue(1024)
out_queue = manager.Queue(1024)
max_processors = 16

with ProcessPoolExecutor(2 + max_processors) as executor:
  executor.submit(read_step, filename, in_queue)
  for _ in range(max_processors):
    executor.submit(process_step, in_queue, out_queue)
  executor.submit(write_step, out_queue)

Время обработки:

Processed 10 videos, took 1.36 seconds
Processed 100 videos, took 6.96 seconds
Processed 1000 videos, took 60.40 seconds

Процессы — наиболее «тяжеловесная» конструкция из рассмотренных. Но только они и подходят для CPU-bound задач.

песочница

#stdlib

Считаем котов: итоги

Некоторые выводы по многозадачности в питоне:

— Даже если программа не использует многозадачность, удобно явно выделить акторов: читателя, обработчика и писателя. С ними код проще понять, модифицировать и повторно использовать.

— Многозадачность через async — отличный легковесный и «родной» вариант для i/o-bound задач. Не забывайте только ограничивать количество одновременных задач.

— Многозадачность через потоки подойдет для i/o-bound задач в легаси-коде, где нет поддержки async. Либо если хотите в перспективе переключиться на процессы с минимальными доработками.

— Многозадачность через процессы подойдет для cpu-bound задач.

Как справедливо отметили в комментариях, async вполне можно комбинировать с процессами. Но об этом как-нибудь в другой раз.

#stdlib

Постраничный итератор для быстрой пакетной обработки

Предположим, вы считаете статистику по огромному датасету игрушек, проданных по всей стране за прошлый год:

reader = fetch_toys()
for item in reader:
  process_single(item)

process_single() занимает 10 мс, так что 400 млн игрушек обработаются за 46 дней 😱

В результате оживленного диалога вам удается убедить разработчиков, что так не очень быстро. На свет появляется функция process_batch(), которая обрабатывает 10000 игрушек за 1 сек. Это уже 11 часов на все игрушки, что значительно приятнее.

Как бы теперь пройти по датасету пакетами по 10 тысяч записей? Тут и пригодится постраничный итератор!

def paginate(iterable, page_size):
  page = []
  for item in iterable:
    page.append(item)
    if len(page) == page_size:
      yield page
      page = []
  yield page

reader = fetch_toys()
page_size = 10_000
for page in paginate(reader, page_size):
  process_batch(page)

Реализация рабочая, но есть проблемка. Такой постраничный обход заметно медленнее обычного итерирования по одной записи:

One-by-one (baseline):   161 ms
Fill page with append(): 227 ms

Если интересно, в чем причина и что можно сделать — читайте подробный разбор.

Постраничные итераторы отлично работают везде, где пакетная операция выполняется сильно быстрее набора одиночных. Рекомендую!

#stdlib

Храним состояние в URL

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

Например, вы продаете через интернет элитный картофель. Покупатель заходит, настраивает фильтры поиска, видит список из 300 позиций.

Переходит на третью страницу, открывает карточку картофелины и случайно нажимает на рефреш страницы. Как поступит ваше приложение?

Я знаю такие варианты:

— Не хранить состояние вообще
— Хранить состояние локально
— Хранить набор URL-параметров
— Хранить сериализованное состояние
— Гибридные подходы

Вот особенности каждого

#код

Как передать состояние в URL-параметрах

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

Строку или число — элементарно:

{
  "search": "potatoes",
  "page": 5
}

→ ?search=potatoes&page=5

Логическое значение — не сильно сложнее:

{ "popular": true }

→ popular=true
  popular=1

Дата и время обычно использует RFC 3339 (2020-01-02T10:11:12Z) или unix time (секунды после полуночи 01.01.1970), реже — миллисекунды:

{ "after": "2020-01-02" }

→ after=2020-01-02
  after=1577923200

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

{ "country": null }

→ country=null
  country=
  <empty>

Список сложнее. Классический вариант — повторять название свойства для каждого значения, как диктует RFC 6570.

Иногда добавляют [], чтобы подчеркнуть, что это список, бывает что и с индексами:

{
  "country": ["bo", "za"]
}

→ country=bo&country=za
  country[]=bo&country[]=za
  country[0]=bo&country[1]=za

Фанаты краткости передают название свойства один раз, а значения разделяют запятыми.

→ country=bo,za

Словарь содержит пары ключ-значение. Чаще всего название основного свойства дублируют, а названия вложенных указывают в []. Реже используют точку.

{
  "size": {
    "min": 3,
    "max": 7
  }
}

→ size[min]=3&size[max]=7
  size.min=3&size.max=7

Вложенность больше 2 уровней обычно не используют.

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

#код

Новости стандартной библиотеки

Когда выходит очередная версия Python, все внимание достается новым фичам языка: моржовому оператору, слиянию словарей, паттерн-матчингу. Еще много пишут об изменениях в асинхронной работе (модуль asyncio) и типизации (модуль typing) — эти модули на виду и бурно развиваются.

Остальным модулям стандартной библиотеки достается незаслуженно мало внимания. Хочу это исправить и рассказать, что интересного появилось в версиях 3.8–3.10.

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

Читайте на хабре:
https://habr.com/ru/post/665020/

P.S. Для каждого описанного новшества в статье есть ссылка на интерактивную песочницу (например, graphlib)! Спасибо Степику за нее ❤️

Компактные объекты

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

Допустим, есть у вас простенький объект «питомец» с атрибутами «имя» (строка) и «стоимость» (целое). Интуитивно кажется, что самое компактное предоставление — в виде кортежа:

("Frank the Pigeon", 50000)

Замерим, сколько займет в памяти один такой красавчик:

def fields():
  # генерит name длины 10
  # и price до 100К
  # ...
  return (name, price)

n = 10_000
pets = [fields() for _ in range(n)]
size = round(asizeof(pets) / n)
print(f"Pet size (tuple) = {size} bytes")

Pet size (tuple) = 161 bytes

161 байт. Будем использовать как основу для сравнения.

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

@dataclass
class PetData:
  name: str
  price: int

А что у него с размером?

Pet size (dataclass) = 257 bytes
x1.60 to baseline

Ого, какой толстенький!

Попробуем использовать именованный кортеж:

class PetTuple(NamedTuple):
  name: str
  price: int

Pet size (named tuple) = 161 bytes
x1.00 to baseline

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

Или нет? В Python 3.10 приехали датаклассы со слотами:

@dataclass(slots=True)
class PetData:
  name: str
  price: int

Pet size (slots dataclass) = 153 bytes
x0.95 to baseline

Ого! Магия слотов создает специальные худощавые объекты, у которых внутри нет словаря, в отличие от обычных питонячих объектов. И такой датакласс ничуть не уступает кортежу.

Что делать, если 3.10 вам еще не завезли? Использовать NamedTuple. Или прописывать слоты вручную:

@dataclass
class PetData:
  __slots__ = ("name", "price")
  name: str
  price: int

У слотовых объектов есть свои недостатки. Но они отлично подходят для простых случаев (без наследования и прочих наворотов).

P.S. Конечно, настоящий победитель — numpy-массив. Но с ним неинтересно соревноваться ツ

песочница

#stdlib