> А почему не erlnag? :-) Или у него другие слабые стороны?
Энларг с диском тоже не очень дружит, зато с сетью все хорошо, лучше Макса Лапшина пораспрашивать в соотв. рассылке 24 ноября 2013 г., 10:18 пользователь Андрей П. Ковбович < [email protected]> написал: > >А если использовать быстрые SSD диски? А если использовать AIO? > > Не знаю насколько актуальны данные, но примерное латенси можно сравнить > тут: http://norvig.com/21-days.html#answers > > > > 24 ноября 2013 г., 9:40 пользователь ksvs <[email protected]> написал: > > >> То есть простой CPU при обращении к диску будет большем, чем затраты CPU >> на сериализацию данных для отправки в сокет шаблонизатора и чтения ответа? >> А если использовать быстрые SSD диски? А если использовать AIO? >> Тут цель, чтобы максимально быстро среагировать на запрос или что-бы не >> простаивал компьютер без полезной нагрузки? >> >> P.S. >> lua внутри nginx? Видал как-то статью про это. >> А почему не erlnag? :-) Или у него другие слабые стороны? >> >> >> On Friday, 22 November 2013, 17:11, Mons Anderson <[email protected]> >> wrote: >> >> On 22.11.2013, at 18:49, ksvs <[email protected]> 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 >> > [email protected] | http://moscow.pm.org >> >> >> -- >> Moscow.pm mailing list >> [email protected] | http://moscow.pm.org >> >> >> >> -- >> Moscow.pm mailing list >> [email protected] | http://moscow.pm.org >> >> >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
