Здравствуйте, n0name2, Вы писали:
N>Нет, я не против kernel mode, просто ничего особенного на динамическом контенте из себя IIS не представляет.
IIS как бы сам по себе никакую динамику не предоставляет. Разве что SSI обозвать динамикой. Так что мне не вполне понятен смысл этого утверждения. N>Нет, на тестах здесь и здесь
Во втором бенчмарке IIS вообще отсутствует как класс.
В первом — показывает себя вполне хорошо:
1. Для non-keepalive рвет Апач как тузик грелку и проигрывает lighthttpd 7416:9254 (около 20%)
2. Для keepalive рвет lighttpd примерно вдвое. Проигрывает только TUX и LSWS 2.0 Pro. Что неудивительно, учитвывая принадлежность тестов
3. Тесты — сосут. Для них использовалась ровно одна клиентская машина, что в корне противоречит реальному назначению web-сервера. В частности, для non-keepalive IIS не смог участвовать в большинстве забегов, т.к. посылал нафиг лишние запросы с того же клиента. Смею ожидать, что использование более реалистичной тестовой загрузки (например, раскидать ее по паре сотен IP адресов, а также моделировать клиентский кэш) может показать совсем другие результаты. В частности, keepalive-запрос на один и тот же файл в жизни не встречается вообще никогда, стало быть то, что они называют "Small Static File KeepAlive" — вообще сферический конь в вакууме.
А тебе я посоветую
а) читать более внимательно. Чтобы впредь не аргументировать свои утверждения опровергающей их статистикой.
б) более критически относиться к синтетическим бенчмаркам.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>2. Для keepalive рвет lighttpd примерно вдвое. Проигрывает только TUX и LSWS 2.0 Pro. Что неудивительно, учитвывая принадлежность тестов
Собсно, TUX или lighthttpd — не суть важно, TUX не имеет к LSWS прямого отношения. Возможно, в других условиях IIS себя и покажет, у тебя есть другие данные?
S>А тебе я посоветую S>а) читать более внимательно. Чтобы впредь не аргументировать свои утверждения опровергающей их статистикой.
Спасибо, учту.
S>б) более критически относиться к синтетическим бенчмаркам.
А по другому объективно сложно оценить performance. Обычно как раз те вендоры, у которых самые большие с ним проблемы и апелируют к тому что мол — вот, все это от лукавого, на реальных задачах мы...
Здравствуйте, n0name2, Вы писали:
N>Собсно, TUX или lighthttpd — не суть важно
Ну нифига себе. Мы же все-таки geeks, или блондинки?
N>, TUX не имеет к LSWS прямого отношения. Возможно, в других условиях IIS себя и покажет, у тебя есть другие данные?
Он вроде как уже показал. По сравнению с большинством вебсерверов он работает просто великолепно. Столь популярный, к примеру, Apache даже в этих тестах сливает иису по полной.
TUX, который тебе так понравился — это интегрированный в ядро линукса веб сервер. Т.е подход используется тот же, что и в http.sys. Выигрыш (кстати, опять же незначительный) может быть связан с сотней разных причин — начиная от настроек логгирования, и заканчивая общей архитектурой ОС. Может оказаться, что на dual CPU TUX уйдет в глубокую дупу.
Вот, кстати, старенький benchmark, выполненный ZDNet: http://www.kegel.com/nt-linux-benchmarks.html#web. Обрати внимание на то, как IIS 5.0 (который еще не умел kernel mode!) рвет Tux2.0 на том же железе. S>>б) более критически относиться к синтетическим бенчмаркам. N>А по другому объективно сложно оценить performance. Обычно как раз те вендоры, у которых самые большие с ним проблемы и апелируют к тому что мол — вот, все это от лукавого, на реальных задачах мы...
Ну, дело-то не в вендорах.
Синтетические бенчмарки нельзя трактовать как финальные обещания: реальные запросы гораздо сложнее. Тем не менее, разницу в несколько раз (IIS:Apache 6:1) трудно догнать просто подкрутив условия теста.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Он вроде как уже показал. По сравнению с большинством вебсерверов он работает просто великолепно. Столь популярный, к примеру, Apache даже в этих тестах сливает иису по полной. S>TUX, который тебе так понравился — это интегрированный в ядро линукса веб сервер. Т.е подход используется тот же, что и в http.sys. Выигрыш (кстати, опять же незначительный) может
быть связан с сотней разных причин — начиная от настроек логгирования, и заканчивая общей
Apache он для других целей, в общем, как high performance сервер его мало кто рассматривает. Любят его потому что очень хорошо ведет себя в shared hosting (если свалился один юзерский процесс, то все остальные ничего не заметят и т.д.). Плюс безопасность (кстати, kernel mode это дырка та еще) и т.д.
архитектурой ОС. Может оказаться, что на dual CPU TUX уйдет в глубокую дупу. S>Вот, кстати, старенький benchmark, выполненный ZDNet: S>http://www.kegel.com/nt-linux-benchmarks.html#web. Обрати внимание на то, как IIS 5.0 (который еще не умел kernel mode!) рвет Tux2.0 на том же железе.
Неверные (неполные?) данные в статье. Смотри первоисточник SPEC.org или вот еще, за другой квартал здесь
Tux 1.0 — 4200 попугаев, IIS 5.0 — 1598.
Кстати, там был 4 way сервер, соот-но масштабируется Tux вполне нормально. Есть results для 8 way...
S>Ну, дело-то не в вендорах.
Как раз к MS доверия меньше всего.
S>Синтетические бенчмарки нельзя трактовать как финальные обещания: реальные запросы гораздо сложнее. Тем не менее, разницу в несколько раз (IIS:Apache 6:1) трудно догнать просто подкрутив условия теста.
Здравствуйте, n0name2, Вы писали:
N>Apache он для других целей, в общем, как high performance сервер его мало кто рассматривает. Любят его потому что очень хорошо ведет себя в shared hosting (если свалился один юзерский процесс, то все остальные ничего не заметят и т.д.).
Гм. То же можно сказать об IIS: падение пула ничему не мешает — просто будет выполнен рестарт. N>Плюс безопасность (кстати, kernel mode это дырка та еще) и т.д.
Гм. По-моему, ты просто фатально не в теме. Kernel mode — не большая дырка, чем драйвер tcp/ip. Тебя не пугает, что он исполняется в режиме ядра?
N>Tux 1.0 — 4200 попугаев, IIS 5.0 — 1598.
Ну вот поэтому я и говорю, что бенчмарки бенчмаркам рознь. В статье приведен резульат за 2001 год, на СПЕК — за 2000.
N>Как раз к MS доверия меньше всего.
Ага. С учетом того, что как раз совершенно независимые измерители показывают их превосходство почти надо всем, что шевелится, это просто смешно. Я, кстати, что-то не нашел никаких бенчмарков от MS.
N>Собственно, в 2.6 раза тоже...
Ага. В это я верю легко: IIS 5.0 ты не шибко-то разгонишь. Он должен работать примерно так же позорно, как апач. А вот шестерка сделана совершенно по другому, что и видно из лайтспидовских тестов, на которые ты сослался.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Гм. То же можно сказать об IIS: падение пула ничему не мешает — просто будет выполнен рестарт.
Рестарт чего? Всего IIS?
N>>Плюс безопасность (кстати, kernel mode это дырка та еще) и т.д. S>Гм. По-моему, ты просто фатально не в теме. Kernel mode — не большая дырка, чем драйвер tcp/ip. Тебя не пугает, что он исполняется в режиме ядра?
Все-таки, чем больше тянуть в kernel mode, тем больше вероятность какого-нить buffer overflow и получение хакером неограниченных привелегий.
N>>Tux 1.0 — 4200 попугаев, IIS 5.0 — 1598. S>Ну вот поэтому я и говорю, что бенчмарки бенчмаркам рознь. В статье приведен резульат за 2001 год, на СПЕК — за 2000.
Вообще говоря, странно что результаты не опубликованы в списке доступных на spec.org, например, за 1й квартал 2001г ничего похожего нет. Во-вторых, железо не совсем идентичное. И наконец, там фигурирует некий SWC (aka Scalable Web Cache), исполняемый в режиме ядра.
Кстати, основные приетензии вообще именно к этим тестам в том, что они тестируют полностью закэшированый fileset, поэтому SWC так себя хорошо в них ведет. Tux типа умеет на правильных NIC передавать данные с диска в сеть напрямую.
N>>Как раз к MS доверия меньше всего. S>Ага. С учетом того, что как раз совершенно независимые измерители показывают их превосходство почти надо всем, что шевелится, это просто смешно. Я, кстати, что-то не нашел никаких бенчмарков от MS.
M>>Вообще предлагают испольщовать MySQL, а на Mnesia реализовать для него кэш
К>Вот мне непонятно почему мускул, а тот же постгрес не пользуется популярностью у эрлангеров.
Возможно из-за наличия вменяемого драйвера для мускла? Под постгрес, помню, в мэйллисте кто-то обещал выложить опенсорсную версию разрабатываемого какой-то компанией драйвера, а воз и ныне там, емнип
Sinclair wrote: > C>Я просто думаю, что это никому особо не нужно. Ну получим ускорение раза > C>в 2 для редких частных случаев, но при этом усложнится вся система и > C>будет уменьшена надежность. > А лично я думаю, что сделать это крайне сложно. В режиме ядра слишком > много ограничений, чтобы можно было безболезненно исполнять произвольное > приложение.
А нам много и не надо — интерфейс для выделения памяти есть, интерфейс к
FS есть, сеть есть. Выигрыш будет за счет того, что с сетью будем
взаимодействовать без переключения контекста.
> Выигрыш в два раза, кстати, это очень дофига. А для > некоторых частных случаев можно было бы и больший получить.
Может быть.
> C>Вот нашел по этому доку: http://www.systemvikar.biz/java_tut/hardcore.xtp > А, не, это малополезная штука. Это всего лишь лоадбалансер, который > форвардит запросы в JVM, работающие естественно в user mode. В принципе, > то же самое делает http.sys.
Насколько я помню (а я помню плохо) он еще умел кэшировать статический
контент. Может и ошибаюсь.
Здравствуйте, n0name2, Вы писали:
N>erjabberd — вполне себе нормальный сервис, не вопрос. только вот ничего сверхъестественного в его performance benchmarks (2000mess/sec, 7000users) я не вижу. Pure Java messaging servers (SoniqMQ например) легко делают 16к сообщений/сек на примерно томже железе...
Мнэээ... Во-первых, как минимум довольно странно сравнивать message-routing framework с полноценным Jabber-сервером, вам не кажется? Во-вторых, где вы нарыли такие тесты: что же такого ужасного надо сделать с ejabberd'ом, чтобы получить 2kmess/sec x 7k? Для сравнения, при переезде jabber.ru на серверы Яндекса, был произведён ряд тестов. Нагрузка генерилась по следующей схеме: раз в 60 секунд добавляли/удаляли ростер, раз в 10 секунд посылали сообщение, раз в 60 секунд меняли статус, раз в 10 минут перелогинивались. Как легко заметить, только на сообщениях (<message/>) генерился 20kmess/sec и это на ~200k сессий (по 100k на ноду, всего две ноды). Конфигурация ноды: 2xXeon 3ghz 64bit, 8Gb RAM, 2x144gb, 1Gb Ethernet; Debian Sarge.
N>...и они более масштабируемы т.к. добавление еще 2-4-8 ядер для таких задач легко даст практически линейный рост.
Увеличивать производительность путём добавления процессоров не очень выгодно. Куда проще да и надёжнее добавить ещё одну дешёвую ноду в кластер. Я вообще не вижу большого практического смысла в SMP в кластерном сетевом софте, это же не числодробилка. А для числодробилок Erlang, ессно, не подойдёт.
Здравствуйте, n0name2, Вы писали: N>Рестарт чего? Всего IIS?
Рестарт пула. N>Все-таки, чем больше тянуть в kernel mode, тем больше вероятность какого-нить buffer overflow и получение хакером неограниченных привелегий.
Фатальность buffer overrun слабо зависит от моды, в которой все исполняется. В кернел моде повыше шанс получить BSOD, чем повышение привилегий.
N>Кстати, основные приетензии вообще именно к этим тестам в том, что они тестируют полностью закэшированый fileset, поэтому SWC так себя хорошо в них ведет. Tux типа умеет на правильных NIC передавать данные с диска в сеть напрямую.
А в чем, собственно, претензия? Современный сайт запросто влезет в пару гигов; поэтому именно аккуратное кэширование статики — ключ к успеху.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали: C>А нам много и не надо — интерфейс для выделения памяти есть, интерфейс к C>FS есть, сеть есть. Выигрыш будет за счет того, что с сетью будем C>взаимодействовать без переключения контекста.
Проблема в том, что
а) в общем случае приложение может потребовать дофига чего еще
б) насколько я понимаю, банальный бесконечный цикл, полученный по ошибке, приведет в kernel mode к катастрофическим последствиям.
Можно обратиться к экспертам по режиму ядра за комментариями. Насколько я понял, в настоящее время программирование в этом режиме — это путь настоящих самураев. Если окажется, что Erlang обеспечивает как раз те гарантии, которые нужны этому режиму для безопасного исполнения софта, то это даст эрлангу огромные преимущества.
C>Насколько я помню (а я помню плохо) он еще умел кэшировать статический C>контент. Может и ошибаюсь.
The current errata:
POST requests are not handled
Date routines have not yet been implemented
Load-balancing is not yet done
Failure to contact a srun results in a disconnect instead of an error message.
/caucho-status isn't implemented yet.
Caching isn't implemented yet.
Logging isn't implemented yet.
HTTP/1.1 keepalive isn't implemented.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote: > C>А нам много и не надо — интерфейс для выделения памяти есть, интерфейс к > C>FS есть, сеть есть. Выигрыш будет за счет того, что с сетью будем > C>взаимодействовать без переключения контекста. > Проблема в том, что > а) в общем случае приложение может потребовать дофига чего еще
Делаем коннектор в userspace, который уже делает что нам нужно — FUSE
так вполне живет. В принципе, это даже можно было бы сделать прозрачно —
некоторые ускоренные модули просто будут работать в режиме ядра, а все
остальное — через коннектор. В общем, http.sys и получится.
> б) насколько я понимаю, банальный бесконечный цикл, полученный по > ошибке, приведет в kernel mode к катастрофическим последствиям.
Нет, к таким же как и в пользовательском — ядерный поток просто
зависнет. Процессор будет занят на 100%, но при желании поток можно
будет убить.
> Можно обратиться к экспертам по режиму ядра за комментариями. Насколько > я понял, в настоящее время программирование в этом режиме — это путь > настоящих самураев.
Ну это если на чистом С без всего.
> Если окажется, что Erlang обеспечивает как раз те > гарантии, которые нужны этому режиму для безопасного исполнения софта, > то это даст эрлангу огромные преимущества.
Собственно говоря, Erlang работает на vxWorks с кучей девяток
стабильности, так что вполне реально.
> C>Насколько я помню (а я помню плохо) он еще умел кэшировать статический > C>контент. Может и ошибаюсь. > The current errata:
C>Собственно говоря, Erlang работает на vxWorks с кучей девяток
не знал... блин как время появится надо будет на наши железки поставить -- народ повеселить и себя показать .
... << RSDN@Home 1.2.0 alpha rev. 655>>
"Бог не терпит голой сингулярности" -- Роджер Пенроуз
Здравствуйте, CiViLiS, Вы писали:
C>>Собственно говоря, Erlang работает на vxWorks с кучей девяток CVL> CVL>не знал... блин как время появится надо будет на наши железки поставить -- народ повеселить и себя показать .
M>Опять не вижу проблемы (в Яве). Используем ScheduledThreadPoolExecutor. Если сообщение не отправили, ставим себя же с новым увеличенным delay-ем в executor, удаляя оттуда же свой текущий экзмепляр. Имхо, должно работать.
Для приведенного примера это действительно работает. Но вот мне очень много приходится писать подобного автоматного кода, т.е. кода, который за один раз выполняет маленький шажок и возвращает управление. Я ЗАКОЛЕБАЛСЯ, если честно. Писанина и отладка подобного кода вручную увеличивает сложность на порядок, по моим личным наблюдениям.
Здравствуйте, zinid, Вы писали:
Z>Мнэээ... Во-первых, как минимум довольно странно сравнивать message-routing framework с полноценным Jabber-сервером, вам не кажется? Во-вторых, где вы нарыли такие тесты: что же такого ужасного
Чем они принципиально отличаются, я так и не понял. JMS тоже хранит состояние каждого клиента — какие ему сообщения доставлены, как еще нет и т.д.
Z>надо сделать с ejabberd'ом, чтобы получить 2kmess/sec x 7k? Для сравнения, при переезде jabber.ru на серверы Яндекса, был произведён ряд тестов. Нагрузка генерилась по следующей схеме: раз в 60 секунд добавляли/удаляли ростер, раз в 10 секунд посылали сообщение, раз в 60 секунд меняли статус, раз в 10 минут перелогинивались. Как легко заметить, только на сообщениях (<message/>) генерился 20kmess/sec и это на ~200k сессий (по 100k на ноду, всего две ноды). Конфигурация ноды: 2xXeon 3ghz 64bit, 8Gb RAM, 2x144gb, 1Gb Ethernet; Debian Sarge.
здесь
Z>Увеличивать производительность путём добавления процессоров не очень выгодно. Куда проще да и надёжнее добавить ещё одну дешёвую ноду в кластер. Я вообще не вижу большого практического смысла в SMP в кластерном сетевом софте, это же не числодробилка. А для числодробилок Erlang, ессно, не подойдёт.
Вообще говоря, как правило, разделяемый state все-таки есть. И если его полностью не удается запухнуть на клиента, то он все-таки хранится в общей памяти или размазывается по кластеру.
В этом случае SMP себя ведет гораздо лучше чем большой кластер, да и разработка существенно проще. Плюс, все-таки, современные процы уже меньше чем с 2я ядрами не делают, в по хорошему нужно брать 4х ядерный камень. Причем, это будет гораздо дешевле чем 4е отдельных бокса. В дальнейшем ситуация, судя по всему, будет развиватся именно в этом направлении.
Здравствуйте, eao197, Вы писали:
E>Создать такой процесс и отладить его -- нет проблем, все весьма тривиально. Причем run-time Erlang-а гарантирует, что система не ляжет, даже если в ней одновременно будут крутиться, скажем 500K таких процессов.
Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, eao197, Вы писали:
E>>Создать такой процесс и отладить его -- нет проблем, все весьма тривиально. Причем run-time Erlang-а гарантирует, что система не ляжет, даже если в ней одновременно будут крутиться, скажем 500K таких процессов.
G>Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем.
Вы делали какие-то тесты? Чем определяется верхний порог?
Здравствуйте, Gaperton, Вы писали:
G>Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем.
Зачем вы дезинформируете людей? :) The maximum number of simultaneously alive Erlang processes is by default 32768. This limit can be raised up to at most 268435456 processes at startup (see documentation of the system flag +P in the erl(1) documentation). The maximum limit of 268435456 processes will at least on a 32-bit architecture be impossible to reach due to memory shortage.
На самом деле основная проблема Erlang'а на 32-битной системе — ограничение на размер кучи в 1699221830 байт (OTP-5596).
1.2.0 alpha rev. 655
