[uanog] Parallel processing - which one to use?

[Volodymyr Litovka]

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 - три отдельных приложения
>>       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
>> 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

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