[Moscow.pm] асинхронный код позволяет сильно сэкономить ресурсы серверов

[Alexander Lourier]

>
> > Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и
>> > больше уже памяти нет.
>> Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному
>> приложению эта память не понадобится? Может, и синхронному не нужна?
>>
>
>  Онлайн-игра. В ней есть много локаций (на данный момент сейчас их 130518
> штук). Про каждую локацию есть примерно килобайт данных. Игрок может
> сделать запрос на прокладку пути из пункта A в пункт B. Надо загрузить граф
> локаций, сделать поиск по нему, вернуть ответ игроку.
>
>  Связность локаций постоянно меняется (игроки открывают/закрывают
> порталы), и граф надо перестраивать. Поэтому загрузить его один раз, а
> потом отфоркать воркеров уже не получается. Поэтому каждый воркер должен
> держать в памяти копию. 130 мегабайт. И это не единственные полезные вещи,
> которые в памяти оседают. Есть и ещё всякое. В результате 50 воркеров едят
> 10 гигов памяти.
>
>  Для решения этой проблемы у меня прокладкой пути занимается отдельный
> сервис, который единственный держит в памяти граф всего мира. Недостаток
> этого решения - latency. Если несколько клиентов хотят проложить путь, они
> это делают по очереди, а процессоры воркеров в это время простаивают.
>
>  Если бы воркеры были асинхронными, то можно было бы запустить 8 воркеров
> (по числу ядер на машине), и на каждый воркер хранилась бы всего одна копия
> графа. Внезапно высвободилась бы куча памяти, которой бы нашлось лучшее
> применение (дисковые кэши, memcached и т.д.)
>
>
>  Вау, мы такую задачу решали на перле лет этак 6 назад.
> prefork + map + async + немного xs.
> Решили так:
> 1) маппили файл с графом на память
> 2) prefork
> 3) перед тем как найти путь или перестроить граф делали flock ( для
> изменения LOCK_EX, для построения LOCK_SH)
> 4) поиск пути делался XS функцей(получалось сильно быстрее), а все
> остальное на perl
>
> 1) В итоге граф не клонируется между форками
> 2) Все процессоры могут поучаствовать в расчете пути.
> 3) единственный минус изменение пути может выполнять один процессор.
>

Угу, хорошее решение. По факту, возможности, отсутствующие в перле
(разделение данных), вы переписали на C.
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150209/001c66ff/attachment.html>