Царю про 10к в надежде перевести дискуссию в конструктив

9% повреждений не то чтобы совсем катастрофа, но уже провал. < ...> Современное железо ещё не стало достаточно крутым, чтобы осиливать 10k потоков с данными на нитях.

а почему вот так сразу «железо»? почему не «ядро»?

знаешь, был такой один студент-недоучка — спал на занятиях, спорил с преподавателями, и писал ядро ос; затем около 2000 г. это ядро с треском слило сравнение на сервинг статических файлов системе на базе microsoft windows ™ — а сетевой стек microsoft windows ™, как мы знаем, сильно заимствовал от *bsd; но потом, почему-то, это ядро приобрело куда большую популярность, чем ядра *bsd — даже для серверов; так ты на этом ядре этого студента, наверно, мерил?

почему не «ядро»?

Кастанем юзеров правильных ядер, может быть проверят https://github.com/i-rinat/c10k-benchmark-fixture

iZEN, buratino, beastie, если вас не затруднит :) Никто другой, к сожалению, не приходит на ум (исключая модераторский состав, сидящий на макос, но кастовать всех сюда чревато)

PS i-rinat, спасибо

В общем, у меня вышло так, что вариант реверс-прокси на нитях из 20000 запросов поломал 1875 (частично).

(частично).

вот в этом хотелось бы разобраться — что же там случалось; ос там четко говорила «ну не смогла я, не смогла!» или же втихую что-то портила?

Современное железо ещё не стало достаточно крутым, чтобы осиливать 10k потоков с данными на нитях.

Ты такой глобальный вывод по одному примеру делаешь? Пока можно утверждать, что твоя реализация твоей сферической задачи не работает. При том, что кроме тестируемого прокси на той же машине крутится тестирующие nginx и apachebench.

А в чем заключаются ``поломки"?

Кастанем юзеров правильных ядер, может быть проверят https://github.com/i-rinat/c10k-benchmark-fixture

есть еще val-amart

При том, что кроме тестируемого прокси на той же машине крутится тестирующие nginx и apachebench.

да хоть wine и microsoft word

вопрос в том, что при поломках говорит ядро (и почему столько много поломок)

А в чем заключаются ``поломки"?

Не разбирался в деталях. Похоже, соединение обрывается. Но там странно — таких соединений по две тыщи, а сообщений об ошибках прокся выдаёт намного меньше, под сотню.

При том, что кроме тестируемого прокси на той же машине крутится тестирующие nginx и apachebench.

Почему-то реализации на epoll это не помешало успешно прокачать через себя всё. Ещё и приличный запас остался.

Ты такой глобальный вывод по одному примеру делаешь? Пока можно утверждать, что твоя реализация твоей сферической задачи не работает.

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

что же там случалось; ос там четко говорила «ну не смогла я, не смогла!» или же втихую что-то портила?

Не вникал, лениво. ab написал, что данных получил меньше, чем ожидал. Видимо, соединение закрывалось.

Прокся выдала пару сотен сообщений в духе «другая сторона закрыла соединение». Возможно, из-за таймаута. Но это не объясняет, почему плохих ответов было под две тысячи. Возможно, что-то не так с обработкой ошибок в коде прокси.

Но там странно — таких соединений по две тыщи, а сообщений об ошибках прокся выдаёт намного меньше, под сотню.

я вполне серьезно подозреваю баги в сетевом стеке линукса, хотя, конечно, надо внимательно посмотреть на твой код

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

А какое утверждение общее?

• Железо может обработать c10k на pthread-ах.
• Железо может обработать c10k на pthread-ах с полезной нагрузкой.
• Железо может обработать c10k на pthread-ах с полезной нагрузкой сравнимо с epoll по накладным расходам.
• Можно подобрать сферическую задачу в вакууме, коротую железо не может обработать c10k на pthread-ах с полезной нагрузкой сравнимо с epoll по накладным расходам.

Мне кажется, ты доказал последнее.

2 www_linux_org_ru

да хоть wine и microsoft word

Ну как то не аккуратненько для тестирования, как мне кажется.

вопрос в том, что при поломках говорит ядро (и почему столько много поломок)

А это да, очень интересно.

А еще очень интересно было бы, если бы Царь согласился запилить свой вариант по этой теме.

А какое утверждение общее?

Чёткой формулировки, конечно, не было. Я обмолвился, что на 300-400 уже будут проблемы, на что на меня вылился ушат ругани. В этой ругани было что-то про «скильные лалки», «гринтреды фуфло», и что-то такое прочее.

Мне интересно, каково это обрабатывать 10 тысяч соединений одновременно. RPS меня не особо волнует. Я знаю, что на коротких соединениях достаточно сделать сделать по потоку на ядро и это даст достаточно хорошую производительность.

Железо может обработать c10k на pthread-ах.

Что такое c10k в твоём понимании?

Ну как то не аккуратненько для тестирования, как мне кажется.

Ну так проведи тестирование аккуратно. Языком трепать все могут, ты дело сделай.

если бы Царь согласился запилить свой вариант по этой теме.

Пфф. Ему интересна абстракция в чистом виде. Не замутнённая, так сказать, практическим применением.

Можно подобрать сферическую задачу в вакууме, коротую железо не может обработать c10k на pthread-ах с полезной нагрузкой сравнимо с epoll по накладным расходам.

гы-гы-гы

нет, он i-rinat решает вполне практическую задачу static file serving на файлопомойке а-ля rapidshare / графических ресурсах для игровых клиентов / ... : сеть скажем 1Гбит/с, на ней висят 10К юзеров, которые тянут со скоростью 10Кбайт/с файлы размером в несколько МБ (цифры условны и показывают масштаб)

Ну как то не аккуратненько для тестирования, как мне кажется.

в чем, собственно, не-аккуратность? я так понял, что nginx & ab были в обоих тестах, так что где проблема?

Железо может обработать c10k на pthread-ах с полезной нагрузкой сравнимо с epoll по накладным расходам.

вот это было бы интересное утверждение (для написания всякого ну-не-суперски-нагруженного-софта из-за большей простоты написания кода, работающего с нитями), однако проблема 9% ошибок пока не дает это утверждение доказать

Чёткой формулировки, конечно, не было.

В том то и дело, что все понимают разное. Так какое утверждение опровергал ты?

Что такое c10k в твоём понимании?

10 000 соединений.

Ну так проведи тестирование аккуратно. Языком трепать все могут, ты дело сделай.

Конечно же, мне лень все это разворачивать и настраивать. Ты выкладывал настройки nginx-а?

www_linux_org_ru

решает вполне практическую задачу static file serving на файлопомойке а-ля rapidshare / графических ресурсах для игровых клиентов / ... : сеть скажем 1Гбит/с, на ней висят 10К юзеров, которые тянут со скоростью 10Кбайт/с файлы размером в несколько МБ (цифры условны и показывают масштаб)

Один файл все 10000 пользователей? На локалхосте? Неужели вы хотите сказать, что это была не симуляция решения определенной задачи, а реальное боевое использование?

вот это было бы интересное утверждение

Так его никто и не обещал изначально.

однако проблема 9% ошибок пока не дает это утверждение доказать

Очень интересно узнать, в чем причина этих ошибок.

Я думаю идея открыть новый тред, что бы Царь смог ответить на предложение написать вариант на pthread-ах, не мноих воодушевит(: ?

Так какое утверждение опровергал ты?

Что ревер-прокси будет нормально работать на тредах. (Если у тебя есть желание копаться в ругани Царя, поисследуй, что он там доказывал. Я не понял.)

10 000 соединений.

Каких? Параллельно, последовательно? Что делают?

Очень интересно узнать, в чем причина этих ошибок.

Интересно. Займёшься?

идея открыть новый тред, что бы Царь смог ответить на предложение написать вариант на pthread-ах

Тут нет предварительной модерации.

Один файл все 10000 пользователей? На локалхосте?

Во-первых, какая разница? Реверс-прокси по большей части не знает, что проксирует. Во-вторых, если на localhost вариант на тредах уже не работает, почему он должен заработать где-то ещё? На localhost условия тепличные.

Я думаю идея открыть новый тред, что бы Царь смог ответить на предложение написать вариант на pthread-ах, не мноих воодушевит(: ?

если «ответить на предложение написать вариант на pthread-ах» означает «объяснить, почему он код писать не будет и заодно вылить еще один ушат помоев», то спасибо, не надо

если же царь существенно подтюнит имеющийся код или напишет свой, без 9% ошибок — то да, это интересно

«сферический в вакууме» означает «интересный (только/в основном) в теоретическом плане»

из трех твоих предложений

1. Железо может обработать c10k на pthread-ах.
2. Железо может обработать c10k на pthread-ах с полезной нагрузкой.
3. Железо может обработать c10k на pthread-ах с полезной нагрузкой сравнимо с epoll по накладным расходам.

1 и 2 как раз и являются «сферическими в вакууме», т.к. разработчик, на практике имеющий задачу «написать нагруженную сетевую аппликуху», заинтересуется не ими, а 3, т.к. положительный ответ на вопрос 3 позволит ему принять практическое решение: писать на pthread-ах и значит упростить написание кода, а вопросы 1 и 2, даже при положительном ответе на них, этого не позволят

Один файл все 10000 пользователей? На локалхосте? Неужели вы хотите сказать, что это была не симуляция решения определенной задачи, а реальное боевое использование?

не хотим сказать, да и не нужно это говорить

но если у тебя есть аргументы в пользу того, что в этой симуляции имелись несправедливые поблажки в сторону epoll (или ptreads), то изложи их

Что ревер-прокси будет нормально работать на тредах. (Если у тебя есть желание копаться в ругани Царя, поисследуй, что он там доказывал. Я не понял.)

А кто это утверждал? Царь ничего про работоспособность прокси не доказывал, на сколько я помню.

Каких? Параллельно, последовательно? Что делают?

Параллельных. Существуют.

Займёшься?

Постараюсь. Я поэтому про настройки nginx и спросил.

Тут нет предварительной модерации.

Тут есть ограничение на доступ анонимусам к 1000постовым темам.

Во-первых, какая разница?

Ну мы про симуляции или реальные задачи?

www_linux_org_ru

если «ответить на предложение написать вариант на pthread-ах» означает «объяснить, почему он код писать не будет и заодно вылить еще один ушат помоев», то спасибо, не надо
если же царь существенно подтюнит имеющийся код или напишет свой, без 9% ошибок — то да, это интересно

Блин, ну тут я точно не знаю, что Царь ответит.

«сферический в вакууме» означает «интересный (только/в основном) в теоретическом плане»

Да.

1 и 2 как раз и являются «сферическими в вакууме», т.к. разработчик, на практике имеющий задачу «написать нагруженную сетевую аппликуху», заинтересуется не ими, а 3, т.к. положительный ответ на вопрос 3 позволит ему принять практическое решение: писать на pthread-ах и значит упростить написание кода, а вопросы 1 и 2, даже при положительном ответе на них, этого не позволят

Насколько я помню, изначально Царь утверждал (1) и (2). Чисто теоретические умозрительные построения. И лишь потом возникла идея проверить (3). Так же чисто умозрительно, для общего развития. Как то так.

не хотим сказать, да и не нужно это говорить
но если у тебя есть аргументы в пользу того, что в этой симуляции имелись несправедливые поблажки в сторону epoll (или ptreads), то изложи их

Нет, я лишь хочу сказать, что из неработоспособности 1 примера на pthread-ах еще не вытекает опровержение (3). И что это тоже отнюдь не проверка на ``реальных задачах".

А кто это утверждал? Царь ничего про работоспособность прокси не доказывал, на сколько я помню.

А я и не с Царём это обсуждаю. Я обрисовал задачу как реверс-прокси, через который текут данные по всем соединениям одновременно. Этот Царь придумал своё, приписал это мне и принялся доказывать обратное. Я в эти игры не играю. Мне интересен конкретный случай.

Параллельных. Существуют.

Мда. А зачем тогда треды? Десять тысяч соединений, которые просто существуют, можно открыть и в одной нити. Это и есть то самое «сферическое в вакууме». Открытие 10000 TCP-соединений это пересылка 30000 пакетов. Такое легко делалось и в 1999-м.

Тут есть ограничение на доступ анонимусам к 1000постовым темам.

Я говорю: «хочешь создать новую тему — создавай. Разрешения не требуется».

Ну мы про симуляции или реальные задачи?

Про симуляции. В реальных задачах такое никто на нитях делать не будет. Допустим, как-то можно вытянуть обработку 10k потоков данных на нитях. На событиях можно вытянуть миллион соединений, если не десять. А нити закончатся на ~125000 соединений при ~16 гигах ОЗУ.

Конечно же я не буду писать нормальный реверс-прокси на нитях. Зачем? Потестить ещё куда ни шло. Но тратить месяцы на создание бессмысленного кода? Это глупость.

Насколько я помню, изначально Царь утверждал (1) и (2). Чисто теоретические умозрительные построения. И лишь потом возникла идея проверить (3). Так же чисто умозрительно, для общего развития. Как то так.

в таком случае наградить эпитетом «сферический в вакууме» следовало в первую очередь код именно царя

напомню, кстати, первую фразу стартового поста:

Я не думаю, что кого-то можно впечатлить принципиальной возможностью запустить 10к потоков для обслуживания клиентов. Когда говорят про встанет раком, имеют в виду неоправданную потерю производительности.

т.е. топик стартер предельно четко и ясно предложил обсудить задачу 3, а не 1 или 2

Ну мы про симуляции или реальные задачи?

мы говорим про те симуляции, которые помогут выбрать подход к решению реальных задач

у отписавшихся тут eao197 и емнип i-rinat-а были конкретные и аргументированные претензии к симуляции царя — они объяснили, почему выводы из нее нельзя будет прилагать к реальным задачам

если у тебя есть претензии к симуляции i-rinat-а, т.е. ты можешь объяснить, почему выводы из нее нельзя будет прилагать к реальным задачам (а точнее, почему симуляция дает несправедливую поблажку какому-то варианту) — welcome

пока что претензии у тебя были (всего 1 файл), но аргументированы они должным образом не были (и кстати, скачивание 1 файла в 10000 соединений вполне реальный юз кейс для случая «клиенты мультиплеерной игры скачивают апдейт графических ресурсов / карт / вселенной», не?)

Нет, я лишь хочу сказать, что из неработоспособности 1 примера на pthread-ах еще не вытекает опровержение (3).

конечно не вытекает; вполне может быть, что:

А. придет добрый человек, и покажет всем, как правильно писать код под 10К нитей

В. код i-rinat-а на нитях нормально заработает под *bsd

я, например, отнюдь не считаю дискуссию по п.3 завершенной, и открыт к дальнейшим новостям по теме

для людей с мозгом добавлю: в русском языке кванторы расставляются неявно; множественное число обычно соответствует квантору всеобщности

Вопиющие 4.2.

Кванторы всеобщности в русском языке указываются явно местоимениями «все» или «каждый».

P.S. Тред, конечно, позорище, и нет, я не про царя.

Кванторы всеобщности в русском языке указываются явно местоимениями «все» или «каждый».

в вашем детском саду или бюрократической тягомотине — да, но не всем это интересно, знаете ли

Ребят весь тред не читал, но если вам для тестов нужен freebsd сервак, есть у меня один. Пока простаивает.

λ xxx ~ →  grep memory /var/run/dmesg.boot
real memory  = 68719476736 (65536 MB)
avail memory = 66647924736 (63560 MB)
λ xxx ~ → sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: amd64
hw.model: Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz
hw.ncpu: 8
hw.machine_arch: amd64

судя по твоему чересчур уверенному заявлению «4.2» ты ничего не понял; но если у тебя хватит мозгов оспорить мою точку зрения, то я буду ее защищать

Кванторы всеобщности в русском языке указываются явно местоимениями «все» или «каждый».

«все» требует множественное число, «каждый» — единственное; мой пойнт в том, что в русском языке «все» — квантор, а «каждый» — это не квантор, а основание для конструктивной процедуры или указание на цикл перебора объектов (если совсем грубо, то «каждый» — это императивная, а не декларативная конструкция)

понятно, что если мы читаем формулу формального языка, мы можем обозначать (читать) квантор словами «для каждого», «каждый», ... но это не означает, что «каждый» в русском языке используется в основном как квантор

если у тебя хватит мозгов оспорить мою точку зрения

У меня хватит мозгов послать тебя читать любой школьный учебник по логике, где популярно разжёвывается как выражение ∀x(A(x) → B(x)) звучит на естественном языке.

У меня хватит мозгов послать тебя читать любой школьный учебник по логике, где популярно разжёвывается как выражение ∀x(A(x) → B(x)) звучит на естественном языке.

отсюда вытекает, что мозгов тебе все же не хватило, чтобы понять, что:

1. язык для чтения формул отличается от языка, на котором разумные носители языка самостоятельно высказывают утверждения, соответствующие формулам

2. я говорил о последнем языке

я поражаюсь, как можно настолько бездумно отвечать на те мои посты, где указано «для людей с мозгом»

Кванторы всеобщности в русском языке указываются явно местоимениями «все» или «каждый».

явно, гы-гы-гы

гуглим первую задачу с формулировкой «медианы треугольника пересекаются в одной точке»

Докажите, что медианы треугольника пересекаются в одной точке и делятся ею в отношении 2:1, считая от вершины треугольника. http://www.problems.ru/view_problem_details_new.php?id=53478

как раз видим неявную расстановку кванторов, при этом ни одного слова «все» или «каждый»; неявно подразумеваются кванторы ∀∀∃ (или ∀∀∀∃, смотря как записывать)

наличие квантора ∃ подчеркивается не только единственным числом, но и словом «одной»

далее там идет подсказка, где один (или 2) квантор(а) ∀ ставят явно («любые»), один ∀ все еще неявно, ∃ неявно/удален

Подсказка Докажите, что любые две медианы делятся точкой их пересечения в отношении 2:1, считая от вершины.