<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div dir="auto">Согласен, это очень просто перенести/запустить серверную часть на клиенте, но как потом сделать: 1) upgrade 2) troubleshooting 3) monitoring 4) etc?</div>
</div>
<div name="messageSignatureSection"><br />
<div class="matchFont">
<div dir="auto">Максим</div>
</div>
</div>
<div name="messageReplySection">On 13 Jan 2021, 18:02 +0100, Volodymyr Litovka <doka@xlit.one>, wrote:<br />
<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;">
<p><br /></p>
<div class="moz-cite-prefix">On 13.01.2021 16:55, Maksym Tulyuk wrote:<br /></div>
<blockquote type="cite" cite="mid:f8a1c78e-bd3f-4279-b927-719234ab1b85@Spark">
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<div name="messageBodySection">
<div dir="auto">Привет!<br />
<br />
Если нужно что-то делать для 1) “для снижения нагрузки на REST” и если 2) "приложение долго тянет базу из REST API”, то это говорит о неправильной архитектуре системы и/или REST API. Но, менять архитектуру дорого и может не получится. Поэтому, в данной ситуации, я бы или 1) оптимизировал REST API для приложения, или 2) написал свой “прокси" REST API и добавлял туда механизмы кеширования.<br /></div>
</div>
</blockquote>
<p>так по сути "проксёй" и является in-memory db. Очень быстрой проксёй.</p>
<p><br /></p>
<blockquote type="cite" cite="mid:f8a1c78e-bd3f-4279-b927-719234ab1b85@Spark">
<div name="messageBodySection"></div>
<div name="messageSignatureSection"><br />
<div class="matchFont"><span style="color: var(--textColor); background-color: var(--backgroundColor);">Максим</span></div>
</div>
<div name="messageReplySection">On 12 Jan 2021, 17:55 +0100, Volodymyr Litovka <a class="moz-txt-link-rfc2396E" href="mailto:doka@xlit.one"><doka@xlit.one></a>, wrote:<br />
<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;">
<p>Привет,</p>
<p>а как правильно подойти к следующей задаче?</p>
<p>Есть приложение (e.g. MyApp), которое обрабатывает данные из нескольких источников:</p>
<pre> +-----------+
| REST API |
+--+-----+--+
| |
PUSH (TCP) | | GET (HTTP)
| |
v v
+---+-----+---+
UDP | | Output
--------->+ MyApp +----------->
| |
+-------------+
</pre>
<p>Поток UDP довольно мощный и является источником RAW data. Для обработки этих данных нужна дополнительная информация, хранящяяся в SQL - она доступа по REST API, а обновления - по TCP PUSH NFYs<br /></p>
<p>Для снижения нагрузки на REST и увеличения собственного быстродействия, при старте MyApp наполняет in-ram cache, запрашивая стартовые данные из REST API и больше никогда к нему не обращаясь, а обновления приходят по TCP (PUSH NFYs)</p>
<p>Таким образом, в процессе работы приложения всегда есть два параллельных процесса, один из которых довольно ёмкий либо по времени, либо по ресурсам -<br /></p>
<p>1) старт - приложение долго тянет базу из REST API, реагируя при этом на периодические TCP PUSH NFYs (тут можно разбить вытягивание большого объема данных на более мелкие чанки)<br />
2) основной цикл работы - приложение слушает очень интенсивный поток UDP (я бы сказал, что делает это без пауз на передохнуть), реагируя при этом на периодические TCP PUSH NFYs</p>
<p>Пока что это пишется на Питоне, что вносит определенные ограничения в набор механизмов. Три варианта, какие я вижу:</p>
<ul>
<li>multiprocess - три отдельных приложения</li>
<ul>
<li>тут более-менее понятно - система сама будет распределять CPU resources между приложениями по требованию + внешняя синхронизация</li>
<li>но выглядит оно эскадрой пушечных парусников из книжки по истории ;-)<br /></li>
</ul>
<li>multithreading - три треда в одном приложении, это уже более "модно и молодежно" (хотя задача синхронизации событий остается), но:</li>
<ul>
<li>гарантируется ли своевременная передача исполнения треду с TCP listener upon packet arrival в услових интенсивной работы треда, обслуживающего UDP?</li>
<li>я читал/слышал, что у Питона сложная история отношений с multi-threading, не наступить бы еще тут на грабли<br /></li>
</ul>
<li>python asyncio</li>
<ul>
<li>это удобно - одно приложение, никакой синхронизации событий между автономными процессами</li>
<li>но вообще это эффективно для такой задачи?<br /></li>
</ul>
</ul>
Что выбрать? Какие еще варианты подхода к снаряду могут быть? Как вообще правильно это делать?<br />
<p>Спасибо!<br /></p>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
_______________________________________________<br />
uanog mailing list<br />
<a class="moz-txt-link-abbreviated" href="mailto:uanog@uanog.kiev.ua">uanog@uanog.kiev.ua</a><br />
<a class="moz-txt-link-freetext" href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a><br /></blockquote>
</div>
<br />
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
uanog mailing list
<a class="moz-txt-link-abbreviated" href="mailto:uanog@uanog.kiev.ua">uanog@uanog.kiev.ua</a>
<a class="moz-txt-link-freetext" href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a></pre></blockquote>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
_______________________________________________<br />
uanog mailing list<br />
uanog@uanog.kiev.ua<br />
https://mailman.uanog.kiev.ua/mailman/listinfo/uanog<br /></blockquote>
</div>
</body>
</html>