[Moscow.pm] Moscow.pm party: доклад-реквесты

[ksvs]

То есть простой CPU при обращении к диску будет большем, чем затраты CPU
 на сериализацию данных для отправки в сокет шаблонизатора и чтения 
ответа?
А если использовать быстрые SSD диски? А если использовать AIO?
Тут цель, чтобы максимально быстро среагировать на запрос или что-бы не простаивал компьютер без полезной нагрузки?


P.S.
lua внутри nginx? Видал как-то статью про это.
А почему не erlnag? :-) Или у него другие слабые стороны?



On Friday, 22 November 2013, 17:11, Mons Anderson <mons на cpan.org> wrote:
 

On 22.11.2013, at 18:49, ksvs <ksvs1996 на ymail.com> wrote:

> 
> У вас шаблонизатор внешний ресурс?! Это ему по сокету дают, например json, а он возвращает html?

Да )

> 
> Я думал, что большинство веб-приложений - получил запрос, пообщался с одной базой данных (3-5 запросов), сформировал html и отдал. Когда ждем ответы от базы, CPU занят обработкой запросов в других процессах. Да и формирование html по шаблону тяжелая ведь задача (наверно).

Тут всегда торговля между: CPU распределяет планировщик между процессами vs CPU распределяется внутри одного процесса.
ШАблонизация на каком-ниубдь xslate это довольно лёгкая (по cpu) задача, но смысл в том, чтоб не заставлять асинхронный процесс обращаться к диску ни при каких обстоятельствах.

> Думал, что "сходить во внешние ресурсы и применить к результатам какую-то простую логику" - это редкие задачи (своя база не в счет). А оказывается наоборот!
> 
> А что это "Есть еще пара случаев, когда синхронка хорошо выигрывает у асинхронки, но они довольно редкие и узкоспециализированные"?
> 
> Это я так засомневался, когда к своей мултипроцесной асинхроной штуке, прикрутил нагрузку по анализу скачиваемых html, и увидел, что вариант с 2 двумя рабочими дочерними процессами (у меня два ядра) и с 100 асинхронных сокетов в каждом дает такую же производительность, как и вариант с 8 рабочими дочерними синхронными процессами. В общем, узкое место стало CPU.
> 
> Кончено, если внешние ресурсы тормозят, то да. Но если они свои, то все быстро.

Пока кол-во дочерних процессов у вас небольшое, то планировщик справляется нормально.
А если обслуживать тысячи параллельных запросов, то тут уже планировщик OS проигрывает асинхронному процессу.

Не обязательно, чтобы ресурсы тормозили.
Поход по сети куда угодно (да даже если это unix сокет) занимает огромное кол-во времени, если считать в тактах cpu.

> 
> В общем, есть пища для размышлений.
> 
> Спасибо.
> 
> P.S.
> Хотя, если логика простая, то можно и на более быстром языке делать ее.
> Скорость еще выше будет. :-)

В принипе иногда пользуемся lua, но если для перла есть все, что только можно вообразить, то для lua набор весьма бедноват.

> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


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