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

Андрей П. Ковбович akovbovich на gmail.com
Сб Ноя 23 22:18:46 PST 2013


>А если использовать быстрые SSD диски? А если использовать AIO?

Не знаю насколько актуальны данные, но примерное латенси можно сравнить
тут: http://norvig.com/21-days.html#answers



24 ноября 2013 г., 9:40 пользователь ksvs <ksvs1996 на ymail.com> написал:

>
> То есть простой 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
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20131124/9f966c23/attachment.html>


Подробная информация о списке рассылки Moscow-pm