Здравствуйте, n0name2, Вы писали:

ANS>>Допустим у тебя 32 проца. Соответсвенно тред пул у тебя на 32 треда. Тебе не кажется это несколько... ограниченным?

N>А в чем проблема? Зачем тебе больше потоков чем процессоров? Единственная причина по которой это нужно — если потоки блокируются на вводе/выводе. Это решается с помощью NIO.

Проблема в том, что при этом либо ты выполняеш не больше 32 задач (этакий продвинутый MS-DOS), либо ты используеш конечный автомат, либо делаеш свои user-level threads.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Я так понимаю, задача — обеспечить максимально конкурентный приём сообщений, а не максимальную пропускную способность (которая будет при схеме "один тред всё время отправляет, потом он всё время принимает"). Отображает ли это исходный тест на Erlang — я не готов сейчас сказать.

Что ты понимаешь под максимальной конкурентностью? Минимальную задержку, среднюю задержку? Средняя задержка в моем решении будет меньше, минимальная, возможно, больше. Если уже речь идет об этом, тут, действительно, нужно подбирать размер пула под заданные требования. Причем, если требование по минимальной задержке разумное, то оно легко ложится на пул при небольших накладных расходах на переключение контекстов.

ANS>Проблема в том, что при этом либо ты выполняеш не больше 32 задач (этакий продвинутый MS-DOS), либо ты используеш конечный автомат, либо делаеш свои user-level threads.

Если ты называешь thread pool конечным автоматом или user-level threads — пусть это будет так, неважно.

N>Кроме того, в случае если работают несколько Erlang schedulers (SMP) там вообще появляются уже расходы на межпроцессное взаимодействие (которое хуже проработано чем в Java наверняка), переключение контекстов и т.д.
F>Наверняка? Я бы не стал утверждать что в Erlang и/или Java где-то, что-то хуже проработано. Всё таки для этого нужно изучать внутренности и первого и второго.

Разработчики JVM занимаются годами оптимизацией блокировок, переключений контекстов и т.д. Опробовано большое кол-во различных методов, вложены огромные деньги. В Erlang поддержка SMP появилась несколько месяцев назад. При всем уважении, я в чудеса не верю. Более того, адетпы Erlang подтверждают это — в SMP конфигурации обмен сообщениями происходит медленнее в разы.

Здравствуйте, n0name2, Вы писали:

F>> На практике non blocking, а по нашенски overlapped не так-то и просто использовать. Куда проще разделить на процессы, потоки и т.д. и т.п.
N>Это только потому, что библиотек нет на .NET нормальных, которые предоставляют несколько более высокий уровень чем raw selectors. На Java есть таже Apache Mina, которая делает все это совершенно тривиальным. Кроме того, по большей части, это вообще скрыто от юзера т.к. этим всем занимается web сервер.
Ага, внимательно пересмотрел твою ссылку. Ну и что? Логичное решение, но вполне себе тривиал, как по мне.
Я про .NET вообще не говорил, а сделать удобные обёртки для overlapped io не такая уж и большая проблема, если такая возможность присутствует в системе. Принимать запросы по nio это круто, но веб-сервер не только с сокетами работает же, а я, глупый, почему-то подумал что у них там что-то более эдакое. Еще раз убеждаюсь, как всё обычно, ничего нового...
Хотя конечно, то что это они сделали — только плюс.

N>Полно бенчмарков и картинок на эту тему. Они похожи на график YAWS vs Apache как две капли воды. Только YAWS интерпретируемый и реально throughput у него гораздо меньше.
Ну хорошо, но как связана интерпретакция с throughput-ом? Всё зависит от того что интерпретируем. Короче меряемся неизвестно чем, хотя бы попугаи были. Так что бестолковый разговор.

Здравствуйте, fddima, Вы писали:

F> Ага, внимательно пересмотрел твою ссылку. Ну и что? Логичное решение, но вполне себе тривиал, как по мне.

Естественно, а ничего сложного и не нужно.

F> Принимать запросы по nio это круто, но веб-сервер не только с сокетами работает же, а я, глупый, почему-то подумал что у них там что-то более эдакое.

А чем он еще занимается? Ты базу имеешь в виду? Это тоже можно сделать в NIO стиле вполне, но, это не актуально т.к. вся ценность NIO в том, чтобы работать с большим кол-вом клиентов с низкой активностью. Кстати, IIS использует overlapped или нет? Вообще, я не очень представляю себе современный web сервер с классической моделью 1 клиент : 1 поток OS (или поток из пула).

F> Ну хорошо, но как связана интерпретакция с throughput-ом? Всё зависит от того что интерпретируем. Короче меряемся неизвестно чем, хотя бы попугаи были. Так что бестолковый разговор.

Ты всерьез веришь что Erlang сможет построить динамическую веб страницу быстрее Java или .NET?

Здравствуйте, n0name2, Вы писали:

N>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>Я так понимаю, задача — обеспечить максимально конкурентный приём сообщений, а не максимальную пропускную способность (которая будет при схеме "один тред всё время отправляет, потом он всё время принимает"). Отображает ли это исходный тест на Erlang — я не готов сейчас сказать.

N>Что ты понимаешь под максимальной конкурентностью?

Принимать сообщения от максимального кол-ва "производителей" за определённое среднее время и не больше чем пороговое максимальное время.

ANS>>Проблема в том, что при этом либо ты выполняеш не больше 32 задач (этакий продвинутый MS-DOS), либо ты используеш конечный автомат, либо делаеш свои user-level threads.

N>Если ты называешь thread pool конечным автоматом или user-level threads — пусть это будет так, неважно.

Блин. У тебя fixed пул на 32 потока. Тебе нужно выполнять 33 действия одновременно. Что делать?

Здравствуйте, n0name2, Вы писали:

N>Полно бенчмарков и картинок на эту тему. Они похожи на график YAWS vs Apache как две капли воды. Только YAWS интерпретируемый и реально throughput у него гораздо меньше.

Дай линк на какие-нибудь картинки, плиз. Интересно посмотреть.

А про интерпретируемость — это неправда, вообще-то. Для эрланга есть HiPE (High Performance Erlang, http://www.it.uu.se/research/group/hipe/), он входит в поставку эрланга с октября 2001-го, компилирует BEAM-файлы в нативный код для платформы.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Принимать сообщения от максимального кол-ва "производителей" за определённое среднее время и не больше чем пороговое максимальное время.
ANS>Блин. У тебя fixed пул на 32 потока. Тебе нужно выполнять 33 действия одновременно. Что делать?

Зачем это нужно? Какое под этим бизнес требование? Сколько занимает исполнение одного действия? Если больше чем "пороговое максимальное время"/2, то переключений контекстов будет относительно мало и накладными расходами можно пренебречь. Если меньше, то 33я задача немного подождет и исполнится. Тут речь идет о сотнях и миллионах сообщений в секунду, я не думаю, что есть осмысленные бизнес задачи, где нужен гарантированный ответ в течение 1:100000й секунды. И для таких задач именно throughput имеет огромное значение т.к. иначе машина просто встанет (вернее, в случае erlang будет обрабатывать некое кол-во сообщений/сек, но, очередь сообщений будет расти очень быстро и в итоге все упадет по out of memory).

Здравствуйте, n0name2, Вы писали:

N>А чем он еще занимается? Ты базу имеешь в виду?
Ну и файлики тоже...

N>Кстати, IIS использует overlapped или нет? Вообще, я не очень представляю себе современный web сервер с классической моделью 1 клиент : 1 поток OS (или поток из пула).
Про IIS не знаю. У нас с его производительностью проблем нет.

N>Ты всерьез веришь что Erlang сможет построить динамическую веб страницу быстрее Java или .NET?
Это то откуда?
Ну да ладно, я не адепт Erlang-а, хотя он мне и нравится больше других ФЛ-языков.
Реальных примеров я что-то не видел с обоих сторон, а выплёвывать простые html-странички для тестов — это не тест. На том же Apache, может быть включён SSI, и столько всякой ерунды, что становится вообще неясно, что с чем сраниваем и где происходит проседание, если вообще происходит.

Ну и необходимости строить динамические страницы у меня сейчас вообще нет, и вроде даже не собираюсь... так что мне нечего на это ответить.
Само собой, я бы выбрал инструмент, который бы мне наиболее подошел, скилов по эрлангу гораздо меньше, чем по дотнету, отсюда можешь сделать вывод -> я бы не стал рисковать делать на эрланге. Да и на работе никто бы не позволил.

Здравствуйте, n0name2, Вы писали:

N>Здравствуйте, Курилка, Вы писали:

К>>Вопрос заключается в том, что создание потока требует накл. расходов, также как и переключение между активными потоками, в отличие модели эрланга, где самым критичным (я думаю) может быть передача больших объёмов данных путём пересылки сообщний.

N>Я говорю о том, что если использовать пулы потоков, то никаких накладных расходов нет. Ни на переключение м/у активными потоками, ни на создание нового. Есть поток, он обрабатывает входную очереди и все. Единственные расходы — это передача данных м/у потоками и засыпание/просыпание потока (когда некоторое время очередь пуста), но, это оч незначительно.

Согласен. Только подходы разные.

N>Накладные расходы в Erlang на переключение наверняка есть. Все-таки там есть stack.

И? Стэк это всего лишь указатель на область памяти, поменять один указатель другим реально тяжёлая операция?

N>Кроме того, в случае если работают несколько Erlang schedulers (SMP) там вообще появляются уже расходы на межпроцессное взаимодействие (которое хуже проработано чем в Java наверняка), переключение контекстов и т.д.

Если честно, но не готов рассказывать как SMP-версия эрланга работает — просто не знаю подробностей. Про "наверняка" не уверен, но спорить не буду — т.к. подробно ни ту ни другую реализацию не знаю. Только одна мысль по поводу того, что явовские потоки не изолированны по данным друг от друга, тогда как в эрланге такого нет.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Создатели языка пишут, что есть, Влад пишет, что нет. Интересно кто прав?

Ссылки, плиз, на то где авторы что-то о гарантиях пишут.

Здравствуйте, n0name2, Вы писали:

ANS>>Допустим у тебя 32 проца. Соответсвенно тред пул у тебя на 32 треда. Тебе не кажется это несколько... ограниченным?

N>А в чем проблема? Зачем тебе больше потоков чем процессоров? Единственная причина по которой это нужно — если потоки блокируются на вводе/выводе. Это решается с помощью NIO.

Хочу отметить, что весь разговор идет вокруг таких задач, которые решаются в рамках одного потока. Для таких задач действительно порождение большего, чем кол-во CPU потоков не нужно.
Если же обсуждать абстрактного коня в вакууме, то пример, когда ограничение на кол-во потоков в пуле является ограничением, привести легко.
Например, решаю я некую задачу, которая хорошо делится на 2 (или N) частей, каждая из которых может решаться отдельно (с возможным соединением результатов в конце). Например, поиск чего-то в интернете (это абстрактный пример), когда каждая порожденная пара потоков обрабатывает свою половину от объема задачи породившего их потока. Сам породивший их поток засыпает, пока не получит от них ответ. В итоге, при такой организации, работать у нас будут только те потоки, которые находятся в листьях этого "дерева". Остальные потоки будут просто загромождать пул.

Хотя я понимаю, что в этой задаче можно оставлять порождающему потоку подчасть задачи.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Проблема в том, что при этом либо ты выполняеш не больше 32 задач (этакий продвинутый MS-DOS), либо ты используеш конечный автомат, либо делаеш свои user-level threads.

Erlang выполняет не больше задач в этой постановке вопроса.

Здравствуйте, VladD2, Вы писали:

ANS>>Создатели языка пишут, что есть, Влад пишет, что нет. Интересно кто прав?

VD>Ссылки, плиз, на то где авторы что-то о гарантиях пишут.

Выбираеш в Янусе пункт меню "Действие" подпункт "Свернуть и перейти в начало темы", читаеш текст.

И, пожалуйста, осуждай Пастернака после прочтения, а не вместо.

Здравствуйте, Курилка, Вы писали:

N>>Полно бенчмарков и картинок на эту тему. Они похожи на график YAWS vs Apache как две капли воды. Только YAWS интерпретируемый и реально throughput у него гораздо меньше.

К>Дай линк на какие-нибудь картинки, плиз. Интересно посмотреть.

Похоже, погорячился насчет полно. В основном, все-таки throughput тестируют, мало кого интересуют сценарии с большим кол-вом keep alive пользователей. Сходу нашел только и . Есть без картинок замеры, но, подтверждают что такая софтина как AsyncWeb совершенно нормально работает с тысячами и десятками тысяч клиентов одновременно.

Здравствуйте, mik1, Вы писали:

M>Например, решаю я некую задачу, которая хорошо делится на 2 (или N) частей, каждая из которых может решаться отдельно (с возможным соединением результатов в конце). Например, поиск чего-то в интернете (это абстрактный пример), когда каждая порожденная пара потоков обрабатывает свою половину от объема задачи породившего их потока. Сам породивший их поток засыпает, пока не получит от них ответ. В итоге, при такой организации, работать у нас будут только те потоки, которые находятся в листьях этого "дерева". Остальные потоки будут просто загромождать пул.

Такого рода задачи не порождают большого кол-ва context switches, соот-но тут Erlang ничем толком не поможет. Согласен, что пул это не silver bullet. Миллион одновременных задач, каждая из которых делится на несколько и собирается в конце вне кластера я слабо себе могу представить. Даже тотже Google такими throughput rates не оперирует.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Ну я надеюсь, я достаточно подробно пояснил, почему я считаю, что Эрланг невозможен под jvm/.net? Хочу правильно поставить акцент: я не отрицаю возможность lightweight библиотеки, я всего лишь навсего очень-очень сильно сомневаюсь, что она может составить конкуренцию Эрлангу на _его_ поле боя и на смежных площадях:

Уважаемые коллеги, обсуждающие, как аналогичные задачи можно успешно решать за счет очередей сообщений и пулов потоков. Мне кажется, вы недооцениваете одной важной вещи, которую предоставляет поход Erlang-а. Если упустить ее из виду, то очередь сообщений действительно может успешно использоваться (равно как и язык ассемблера в умелых руках). Разница всего лишь в цене и в возможностях.

А предоставляет Erlang такую штуку, как возможность оформить какую-либо автономную операцию в виде самостоятельного процесса. И наплодить таких процессов сотни тысяч. И не иметь с этим делом большого геморроя, прибивая за просто так любой процесс и очень дешево порождая новый процесс. И все это в террариуме, в котором копошатся тысячи и тысячи процессов.

В качестве примера возьмем гипотетическую доставку подписчикам RSDN текстов новых постов в виде e-mail сообщений (пример актуальный кстати, т.к. изрядный процент сообщений теряется). Предположим, что процедура доставки одного сообщения одному абоненту оформляется в виде самостоятельного процесса. Он использует механизм гарантированной доставки, повторяя попытки отсылки сообщения с возрастающим тайм-аутом после каждой неудачи. После N неудачных попыток процесс просто завершает свою работу ("на нет и суда нет"). Реализовать такой процесс в виде одного for-а не составляет труда (извините, пример не на Erlang-е, а на псевдо-языке):

deliver_message( post, recipient )
{
  for(i = 0; i != N; ++i )
  {
    result = try_deliver( post, recipient );
    if( ok != result )
    {
      // Если временная проблема доставки, то есть
      // смысл повторить ее позже.
      if( can_be_delivered_later( result ) )
        sleep( (i+1)*TIMEOUT );
      else
        // Если SMTP сервера нет или он говорит, что
        // такого получателя нет, то просто прекращаем
        // дальнейшие попытки.
        die( post, recipient, THESE_STUPID_BEES_MAKE_INVALID_HONEY );
    }
    else
      // Сообщение отправлено.
      die( post, recipient, HAVE_A_NICE_DAY );
}

Функция die может помечать в базе, что сообщение на данного абонента доставлять больше не нужно (для корректного продолжения работы после рестартов).

Создать такой процесс и отладить его -- нет проблем, все весьма тривиально. Причем run-time Erlang-а гарантирует, что система не ляжет, даже если в ней одновременно будут крутиться, скажем 500K таких процессов.

А вот альтернативные решения требуют несколько больших усилий. Самый простой вариант -- рескан с каким-то периодом базы в поиске пар сообщение/абонент, которым нужно произвести доставку. Но для того, чтобы протестировать его под нагрузкой придется сильно попотеть, набивая тестовую БД и имитируя различные исходы доставки сообщения. А так же верификации результатов тестирования.

Чуть более сложный вариант -- организация каждой пары сообщение/абонент в виде объекта. Этот объект ставится в очередь. Когда какая-то из нитей рабочего пула извлекает такой объект, она выполняет очередную попытку доставки, затем анализирует разультат доставки и принимает решение о том, что делать дальше. Здесь нужно придумывать, как ставить в очереди "отложенные" объекты, время повторной доставки которых далеко "в будущем" -- ведь вытащив такую заявку из вершины очереди рабочая нить должна понять, что еще рано, вернуть объект обратно и заснуть "до лучших" времен. Нужно самим делать механизм "прибивания" рабочих нитей которые из-за каких-то сбоев в функции try_deliver не возвращаются из обрабоки очередного сообщения.


Вот как-то так. Или я что-то не правильно про Erlang понял?

Здравствуйте, n0name2, Вы писали:

N>Такого рода задачи не порождают большого кол-ва context switches, соот-но тут Erlang ничем толком не поможет. Согласен, что пул это не silver bullet. Миллион одновременных задач, каждая из которых делится на несколько и собирается в конце вне кластера я слабо себе могу представить. Даже тотже Google такими throughput rates не оперирует.

Да задачу представить то несложно.
Найти все сайты в интернете, в которых встречается строка "n0name2". Допускать, что у нас в массиве (или индексированной возврастающими по порядку числами табличке в БД) уже лежит список всех доменных имен Интернета.
Процессоры быстрые, коннект к инету явно медленнее. Все равно имеет смысл порождать очень много потоков. Тут размер пула заранее не задашь.

Но вообще это да, демагогия

Здравствуйте, eao197, Вы писали:

E>А предоставляет Erlang такую штуку, как возможность оформить какую-либо автономную операцию в виде самостоятельного процесса. И наплодить таких процессов сотни тысяч. И не иметь с этим делом большого геморроя, прибивая за просто так любой процесс и очень дешево порождая новый процесс. И все это в террариуме, в котором копошатся тысячи и тысячи процессов.

Если опустить слово "убивать", то executor-ы в Яве эти самые АВТОНОМНЫЕ операции выполняют не хуже.
Если надо убивать, то см конец поста.

E>А вот альтернативные решения требуют несколько больших усилий. Самый простой вариант -- рескан с каким-то периодом базы в поиске пар сообщение/абонент, которым нужно произвести доставку. Но для того, чтобы протестировать его под нагрузкой придется сильно попотеть, набивая тестовую БД и имитируя различные исходы доставки сообщения. А так же верификации результатов тестирования.

Опять не вижу проблемы (в Яве). Используем ScheduledThreadPoolExecutor. Если сообщение не отправили, ставим себя же с новым увеличенным delay-ем в executor, удаляя оттуда же свой текущий экзмепляр. Имхо, должно работать.


E>Чуть более сложный вариант -- организация каждой пары сообщение/абонент в виде объекта. Этот объект ставится в очередь. Когда какая-то из нитей рабочего пула извлекает такой объект, она выполняет очередную попытку доставки, затем анализирует разультат доставки и принимает решение о том, что делать дальше. Здесь нужно придумывать, как ставить в очереди "отложенные" объекты, время повторной доставки которых далеко "в будущем" -- ведь вытащив такую заявку из вершины очереди рабочая нить должна понять, что еще рано, вернуть объект обратно и заснуть "до лучших" времен. Нужно самим делать механизм "прибивания" рабочих нитей которые из-за каких-то сбоев в функции try_deliver не возвращаются из обрабоки очередного сообщения.

Эммм... try_deliver вызывает внешний код в обоих случаях (Erlang и C#/Java) или же пользуется внутренним кодом?
Для внешнего кода убивать поток одинаково невесело и там и там.
Во внутреннем коде при желании код отправки сообщений можно оснастить вызовами аналогичными Явовскому Thread.currentThread.isInterrupted()
Так что ниточки при желании прибивать можно и там и там.

Здравствуйте, mik1, Вы писали:

M>Да задачу представить то несложно.
M>Найти все сайты в интернете, в которых встречается строка "n0name2". Допускать, что у нас в массиве (или индексированной возврастающими по порядку числами табличке в БД) уже лежит список всех доменных имен Интернета.
M>Процессоры быстрые, коннект к инету явно медленнее. Все равно имеет смысл порождать очень много потоков. Тут размер пула заранее не задашь.

В чистом виде задача для Non blocking IO... Просто классический пример.

Здравствуйте, eao197, Вы писали:


E>В качестве примера возьмем гипотетическую доставку подписчикам RSDN текстов новых постов в виде e-mail сообщений (пример актуальный кстати, т.к. изрядный процент сообщений теряется). Предположим, что процедура доставки одного сообщения одному абоненту оформляется в виде самостоятельного процесса. Он использует механизм гарантированной доставки, повторяя попытки отсылки сообщения с возрастающим тайм-аутом после каждой неудачи. После N неудачных попыток процесс просто завершает свою работу ("на нет и суда нет"). Реализовать такой процесс в виде одного for-а не составляет труда (извините, пример не на Erlang-е, а на псевдо-языке):

Тоже совершенно классическая NIO задача. Здесь вообще никакого пула не нужно, все в одном потоке.