[uanog] Parallel processing - which one to use?

[Vladimir Sharun]

Привет,

Постановка задачи требует уточнений. Надо понимать:
на каждый UDP пакет надо принимать решение, основываясь на критериях из кэша/апдейтов_в_пуше ? что это ?
какой поток UDP пакетов/с, размеры, надо как-то парсить? большие ? Например сразу будь готов к написанию еще с порога системы контроля версии датасета в базе и у тебя в кэше, потому что вот эти "усилители класса А без обратной связи" - часто жертвы самоуверенности (рейс про@бали, дата не так проинтерпретировалась и т.п.) и в базе одно, а делаем другое

Пока что сходу решение -  С++/Асинхрон/воркеры, типичный пример тут - nginx.

Да, и inram cache - это тоже штука в себе.

12 січня 2021, 18:55:22, від "Volodymyr Litovka" <doka at xlit.one>:

Привет,
а как правильно подойти к следующей задаче?
Есть приложение (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/20210112/64055dbf/attachment-0001.html>