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

[Warstone@list.ru]

 Асинхронно в любом случае будет "в порядке очереди событий, как тебе ядро сгенерит". select не беру в рассмотрение. Или мы уже асинк не через epoll/kqueue научились делать?
Синхронно - это "я жду ответа", а как меня там ОС будет менеджерить - это проблемы ОС, а не мои. 


Понедельник, 09 февраля 2015, 18:55 +04:00 от Andrey Kovbovich <akovbovich на gmail.com>:
>Прошу развернуть свою мысль. Если для тебя асинхронно значит мультиплексирование коннектов через один канал, то наверное мы о разном немного.
>
>понедельник, 9 февраля 2015 г. пользователь  Warstone на list.ru написал:
>>Неверно в принципе, ну да ладно...
>>
>>Понедельник, 09 февраля 2015, 17:09 +04:00 от Andrey Kovbovich < akovbovich на gmail.com >:
>>>Асинхронно - это когда несколько потоков исполнения работают как им возблагорассудиться, а синхронно - это когда потоки работают в соответствии некому генератору квантов логического  времени
>>>
>>>понедельник, 9 февраля 2015 г. пользователь Daniel Podolsky  написал:
>>>>> Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и
>>>>> больше уже памяти нет.
>>>>Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному
>>>>приложению эта память не понадобится? Может, и синхронному не нужна?
>>>>--
>>>>Moscow.pm mailing list
>>>>moscow-pm на pm.org  |  http://moscow.pm.org
>>>-- 
>>>Moscow.pm mailing list
>>>moscow-pm на pm.org |  http://moscow.pm.org
>>
>>Собственно тут вроде-бы еще не проскальзывала мысль, что асинхронность, при условии достаточности ресурсов - это всегда медленнее чем синхронность. Например: Я зажевал в один поток все сообщения, раздал запросы на данные и обрабатываю результаты.... Пока я обрабатываю один результат, остальные стоят. В случае с синхронным форком такого-бы не было (у нас много ядер).
>>
>>Проблема назревает когда у нас бекэнд (то, что отвечает на запросы), обрабатывает запрос долго. Но в этом случае какая, нафиг, кому разница - где делается "асинхронность" - у нас в лупе или в ядре при свитче контекста. Бек все-равно дольше...
>>
>>Асинхронность нужна в некоторых случаях:
>>- Если у вас стоимость свитча контекста гораздо дороже ответа от бэка (по времени), но при переходе на асинк у вас еще будет дофига ресурсов ЦПУ (так как свитч контекста - это ЦПУ задача).
>>- Если у вас асинк дает другие преимущества (в то числе и "потому что его умеют готовить разработчики, а вот с форком им сложно").
>>- Если у вас задача "обработать данные, зная что у вас в очереди всегда есть следующие задачи". Допустим быстрое преобразование фурье с отсылкой результатов далее по конвееру. (Привет  SETI на Home) Вот тогда - да. Тогда есть у вас CPU баунд задача и вам важны такты процессора.
>>
>>На практике мы всегда боимся 1го, но зачастую протормозы в беках гораздо больше.
>>
>>ЗЫ: Тоже поучаствовать решил.
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150209/0d063b34/attachment-0001.html>