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

[Андрей П. Ковбович]

> А почему не erlnag? :-) Или у него другие слабые стороны?

Энларг с диском тоже не очень дружит, зато с сетью все хорошо, лучше Макса
Лапшина пораспрашивать в соотв. рассылке


24 ноября 2013 г., 10:18 пользователь Андрей П. Ковбович <
akovbovich на gmail.com> написал:

> >А если использовать быстрые 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/75584f43/attachment-0001.html>