[uanog] Parallel processing - which one to use?

[Maksym Tulyuk]

Привет!

Если нужно что-то делать для 1) “для снижения нагрузки на REST” и если 2) "приложение долго тянет базу из REST API”, то это говорит о неправильной архитектуре системы и/или REST API. Но, менять архитектуру дорого и может не получится. Поэтому, в данной ситуации, я бы или 1) оптимизировал REST API для приложения, или 2) написал свой “прокси" REST API и добавлял туда механизмы кеширования.

Я всегда предпочитаю multiprocess системы т.к. unix команды kill/top/nice/renice уже существуют десятки лет, прекрасно работают и лишняя complexity здесь не нужна.

Написание программы с “параллельной”/одновременной работой процессов без locks, shared memory, stateful objects, mutable variables и т.п. требует знаний и навыков, которые есть у очень малого кол-ва программистов. Поэтому, если слова functional programming вызывает только негативные эмоции, но лучше ИМХО и не пытаться.

Максим
On 12 Jan 2021, 17:55 +0100, Volodymyr Litovka <doka at xlit.one>, wrote:
> Привет,
> а как правильно подойти к следующей задаче?
> Есть приложение (e.g. MyApp), которое обрабатывает данные из нескольких источников:
>            +-----------+
>            |  REST API |
>            +--+-----+--+
>               |     |
>    PUSH (TCP) |     | GET (HTTP)
>               |     |
>               v     v
>           +---+-----+---+
>   UDP     |             |   Output
> --------->+   MyApp     +----------->
>           |             |
>           +-------------+
>
> Поток UDP довольно мощный и является источником RAW data. Для обработки этих данных нужна дополнительная информация, хранящяяся в SQL - она доступа по REST API, а обновления - по TCP PUSH NFYs
> Для снижения нагрузки на REST и увеличения собственного быстродействия, при старте MyApp наполняет in-ram cache, запрашивая стартовые данные из REST API и больше никогда к нему не обращаясь, а обновления приходят по TCP (PUSH NFYs)
> Таким образом, в процессе работы приложения всегда есть два параллельных процесса, один из которых довольно ёмкий либо по времени, либо по ресурсам -
> 1) старт - приложение долго тянет базу из REST API, реагируя при этом на периодические TCP PUSH NFYs (тут можно разбить вытягивание большого объема данных на более мелкие чанки)
> 2) основной цикл работы - приложение слушает очень интенсивный поток UDP (я бы сказал, что делает это без пауз на передохнуть), реагируя при этом на периодические TCP PUSH NFYs
> Пока что это пишется на Питоне, что вносит определенные ограничения в набор механизмов. Три варианта, какие я вижу:
>
> • multiprocess - три отдельных приложения
>     • тут более-менее понятно - система сама будет распределять CPU resources между приложениями по требованию + внешняя синхронизация
>     • но выглядит оно эскадрой пушечных парусников из книжки по истории ;-)
> • multithreading - три треда в одном приложении, это уже более "модно и молодежно" (хотя задача синхронизации событий остается), но:
>     • гарантируется ли своевременная передача исполнения треду с TCP listener upon packet arrival в услових интенсивной работы треда, обслуживающего UDP?
>     • я читал/слышал, что у Питона сложная история отношений с multi-threading, не наступить бы еще тут на грабли
> • python asyncio
>     • это удобно - одно приложение, никакой синхронизации событий между автономными процессами
>     • но вообще это эффективно для такой задачи?
>
> Что выбрать? Какие еще варианты подхода к снаряду могут быть? Как вообще правильно это делать?
> Спасибо!
> --
> Volodymyr Litovka
>  "Vision without Execution is Hallucination." -- Thomas Edison
> _______________________________________________
> uanog mailing list
> uanog at uanog.kiev.ua
> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20210113/f34fc6a8/attachment-0001.html>