[uanog] Parallel processing - which one to use?

[Volodymyr Litovka]

Привет,

On 12.01.2021 19:12, Vladimir Sharun wrote:

> Постановка задачи требует уточнений. Надо понимать:
>
>  1. на каждый UDP пакет надо принимать решение, основываясь на
>     критериях из кэша/апдейтов_в_пуше ? что это ?
>
каждый пакет - это текстовая строка, состоящая из 4-х полей, по одному 
из которых делается if и есличо, то три других проходят проверки на 
валидность и, дополняясь информацией из local cache, уходят в output

что-то типа

while True:
     data, address = lsock.recvfrom(1024)
     try:
         a, b, c, d = [i.strip()) for i in data.decode().split(',)]
         a = int(a)
         if a == 255:
            if not b.isnumeric():
                continue
            va = memcached.get(b)
            if va:
                IPAddress(c)
                d = int(d)
                # we're here because no exception above
                data = b.decode() + socket.inet_aton(c) + d.from_bytes(2, 'big) + va
                for r in remotes:
                    rsock.send(data, r)	# output UDP
         elif a in [3, 5, 7]:
            # smth else
            ...
     except:
         pass

реально - это практически всё как в оригинале, логика простая и 
прямолинейная, потому ...

>  1. какой поток UDP пакетов/с, размеры, надо как-то парсить? большие ?
>
я (наивно?) полагаю, что несколько тысяч pps питон вытянет на среднем 
железе (у меня нет подобного опыта и отталкиваться не от чего), а потом 
таки да -

> On 12.01.2021 19:19, Mykola Ulianytskyi wrote:
>>   > Что выбрать?
>>
>> C++ / C# / Java
уйти на Java


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

была такая мысль, спасибо


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

ну nginx - это ультра-факин-фотонный звездолет по сравнению с тем, что 
написано выше :)


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

а какая разумная альтернатива?


>
> /12 січня 2021, 18:55:22, від "Volodymyr Litovka" <doka at xlit.one 
> <mailto: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 - три отдельных приложения
>           o тут более-менее понятно - система сама будет распределять
>             CPU resources между приложениями по требованию + внешняя
>             синхронизация
>           o но выглядит оно эскадрой пушечных парусников из книжки по
>             истории ;-)
>       * multithreading - три треда в одном приложении, это уже более
>         "модно и молодежно" (хотя задача синхронизации событий
>         остается), но:
>           o гарантируется ли своевременная передача исполнения треду с
>             TCP listener upon packet arrival в услових интенсивной
>             работы треда, обслуживающего UDP?
>           o я читал/слышал, что у Питона сложная история отношений с
>             multi-threading, не наступить бы еще тут на грабли
>       * python asyncio
>           o это удобно - одно приложение, никакой синхронизации
>             событий между автономными процессами
>           o но вообще это эффективно для такой задачи?
>
>     Что выбрать? Какие еще варианты подхода к снаряду могут быть? Как
>     вообще правильно это делать?
>     Спасибо!
>
>     -- 
>     Volodymyr Litovka
>        "Vision without Execution is Hallucination." -- Thomas Edison
>
>     _______________________________________________
>     uanog mailing list
>     uanog at uanog.kiev.ua  <mailto:uanog at uanog.kiev.ua>
>     https://mailman.uanog.kiev.ua/mailman/listinfo/uanog  <https://mailman.uanog.kiev.ua/mailman/listinfo/uanog>
>
-- 
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20210112/b1752304/attachment-0001.html>