[uanog] Parallel processing - which one to use?

[Maksym Tulyuk]

Согласен, это очень просто перенести/запустить серверную часть на клиенте, но как потом сделать: 1) upgrade 2) troubleshooting 3) monitoring 4) etc?

Максим
On 13 Jan 2021, 18:02 +0100, Volodymyr Litovka <doka at xlit.one>, wrote:
>
> On 13.01.2021 16:55, Maksym Tulyuk wrote:
> > Привет!
> >
> > Если нужно что-то делать для 1) “для снижения нагрузки на REST” и если 2) "приложение долго тянет базу из REST API”, то это говорит о неправильной архитектуре системы и/или REST API. Но, менять архитектуру дорого и может не получится. Поэтому, в данной ситуации, я бы или 1) оптимизировал REST API для приложения, или 2) написал свой “прокси" REST API и добавлял туда механизмы кеширования.
> так по сути "проксёй" и является in-memory db. Очень быстрой проксёй.
>
> >
> > Максим
> > 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
> >
> > _______________________________________________
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20210116/fbdd9a83/attachment-0001.html>