[uanog] Parallel processing - which one to use?

[Volodymyr Litovka]

> On 13 Jan 2021, at 09:11, Mykola Ulianytskyi <lystor at gmail.com> wrote:
> 
>> а какая разумная альтернатива?
> 
> 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