[uanog] Parallel processing - which one to use?

[Mykola Ulianytskyi]

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

Redis

--
Best regards,
Mykola

--
Best regards,
Mykola


On Tue, Jan 12, 2021 at 10:47 PM Volodymyr Litovka <doka at xlit.one> wrote:
>
> Привет,
>
> On 12.01.2021 19:12, Vladimir Sharun wrote:
>
> Постановка задачи требует уточнений. Надо понимать:
>
> на каждый 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
>
> реально - это практически всё как в оригинале, логика простая и прямолинейная, потому ...
>
> какой поток 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>:
>
> Привет,
> а как правильно подойти к следующей задаче?
> Есть приложение (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
>
> --
> 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