Ну в простейшем случае такой сайт занимается sendfile webm-файла в тег <video>

Ну в простейшем случае такой сайт занимается sendfile webm-файла в тег <video>

Так ведь и в простейшем случае приходится решать вопросы тайм-аутов, например, медленных клиентов и пр.

Ну и да, HTTP-заголовки от клиента сперва же распарсить нужно :)

Да пожалуйста. Вот с чего все началось:

Мало. Началось явно не с этого. Я потом зарегаюсь и посмотрю.

Ну а вот два твоих решения: https://godbolt.org/g/HcDQLD и https://godbolt.org/g/tnDvAJ

Первое решение - это пример-укор в пользу той лапши, что ты там наваял. Второе - это единственное решение, которое реально работает.

Особенно смешно выглядят отмазки типа «это просто у меня ограничение было С++14 - я не виноват, что наваял убогой лапши». Верю.

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

Еще раз, для полных дебилов: чтение и запись не пойми чего никому не всралось. Вообще. Только когда к чтению и записи добавляется какая-то осмысленная обработка, только тогда проблема 10k приобретает смысл.

Очередной пердёжь в лужу. Ты не привёл ни единого основания для того, что пытаешься тут болтать. Да и к тому же заигнорил всё то, что я писал по этому поводу.

В очередной раз я могу констатировать только слив.

В очередной раз я могу констатировать только слив.

Ты как тот голубь, в очередной раз разбросал фигуры и насрал на доску.

Так ведь и в простейшем случае приходится решать вопросы тайм-аутов, например, медленных клиентов и пр.

Я не понимаю. Ты реально настолько туп? Я понимаю, что ты пытаешься ретранслировать того пятизвёздочного балабола, но всё же. Никаких «тайм аутов» не существует, никаких «медленных клиентов» то же. Их медленность ни на что не влияет.

Вся запись и всё чтение буферизовано и на клиенте и на сервере. От этого не важно насколько и как будет выполняться чтение и запись - это ни на что не повлияет.

Частично - это может повилять на чтение, где рид будет раздупляться на сотне байт, но ни на что - опять же это не повлияет.

Ну и да, HTTP-заголовки от клиента сперва же распарсить нужно :)

И это ни на что не повиляет. Увеличится только время обработки запроса и увеличится они чисто за счёт оверхеда на парсинг хттп.

К потокам и прочему это отношения не имеет.

Да, да. Кукареку-кукареку. Ноль конкретики - одно балабольство.

Никаких «тайм аутов» не существует, никаких «медленных клиентов» то же.

Бл*, как же я хочу жить в такой вселенной :)

Их медленность ни на что не влияет.
И это ни на что не повиляет.

И тебя вылечат, и меня вылечат (c)

беру свой пример назад... Я был не прав.

Ловите момент. Это выражения, которое вы больше никогда не услышите в царетредах.

А разве он должен быть?

Уж лучше я буду сидеть в ужасном «климате», чем с неадекватами типа царя.

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

гы гы гы, и как это мы ту сниферами то пользуемся, но походу за рамками шоу. пожую попкрон дальше.

Вы не знаю, но вообще сниферы переводят сетевую карту в «не разборчивый режим» и загружают в свой буфер чтения (подчеркиваю свой, который на клиенте) все проходящие по сети пакеты, но ,я думаю, вы и так это знаете. Вопрос состоял в том - если одновременно читать и писать в один и тот же сокет вознет ли информационная петля? Если буферы чтения и записи разъедены - то нет, иначе да. Судя по всему они разъединены. Но вы выхватив по кускам как то не дошли до этого момента в наших рассуждениях и уже преготовили попкорн - не подавитесь, обильно запивайте.

А то, что ты мог запутать пацана и подбить его под нужное тебе условие - из этого мало что следует.

Привет! :-) Нет, он не подбил никого под нужное условие :-) Тогда была демонстрация ущербности цепепе что с его, что с твоей стороны :-) Но у тебя действительно получилось показать, как ты выразился, «животворящий компайл-тайм» :-) В отличии от твоего собеседника :-) А так то да, то, что в Лиспе строки конкатенируются в компайл-тайме в 1-2 строчки, да ещё и так, что этим реально можно пользоваться на фоне простыни невменяемой тарабарщины на цепепе просто ради доказательства на форуме (а не для практического использования), показывает, что цепепе по факту не умеет в компайл-тайм строки :-)

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

Совершенно верно :-)

Ок, тогда зачем ты кресты люто хейтил?

О боже, домохозяйка даже в базовых понятиях запуталось. Но зато эксперт всея лора. vm == virtual memory, я думаю ты далее ты сможешь по ключевым словам погуглить.

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

У процесса контекст состоит не только из регистров. Ключевые слова я уже написал. И миф о том, что контекстсвич прям дожопы дорогая операция( как и сисколы) основан именно что на медленным переключением адресных пространств.

Я их и сейчас хейтю. Как и сишку. Дерьмо оно и есть дерьмо, но лучше ничего нет. И из-за того, что лучше ничего нет - дерьмо не перестаёт быть дерьмом. Такие дела.

Да и «хейтил» - это про вас, а не про меня. Я критикую, а не хейчу.

я нигде не писал, про сетевые. Да и понятие сокет не только сраная сеть. ну а теперь нарисуй сокет, и подумай хорошенько, а то мне жутко лень, у меня руки попкорном заняты.

Да потому, что чтение и запись, никак не привязанная хоть к какой-то практически-значимой обработке данных никому нахер не всралась. Ну вот вообще.

Если вы обсуждаете c10k, то и обсуждайте c10k. Не надо подменять тему, это вся претензия царя. Хотите обсудить другую тему? Для неё будет другой термин. Под данным термином понимается то, о чём пишет царь. Неужели сложно нормально включить заднюю, а не усираться?

C10k problem From Wikipedia, the free encyclopedia The C10k problem is the problem of optimising network sockets to handle a large number of clients at the same time.[1] The name C10k is a numeronym for concurrently handling ten thousand connections.[2] Note that concurrent connections are not the same as requests per second, though they are similar: handling many requests per second requires high throughput (processing them quickly), while high number of concurrent connections requires efficient scheduling of connections. In other words, handling many requests per second is concerned with the speed of handling requests, whereas a system capable of handling high number of concurrent connections does not necessarily have to be a fast system, only one where each request will deterministically return a response within a (not necessarily fixed) finite amount of time.

опять половину прочел и пошел шпарить. ЛОР - он такой лор. Повторяю проблема исчерпана, со всем разобрались и твое мнение не интересно. Приятного аппетита.

Да да, я заедаю, продолжайте.

Бл*, как же я хочу жить в такой вселенной :)

Ты в ней итак живёшь. Если бы ты действительно пытался разобраться в том, о чём пытаешься говорить - тебе бы стало настолько проще жить.

Таймаутов на уровне юзерпейса для транспортного уровня не существует. Как максимум ручки.

Работа с медленными клиентами никак не отличается от работы с быстрыми. Медленности не существует на уровне юзерпейса. Ты пишешь в буфер и читаешь из буфера, твой клиент пишет в буфер и читает из него же. Пакет в 1байт тебе не пошлётся. А даже если пошлётся - это ничего не поменяет.

Точно так же и с обработкой. Ты работаешь над данными, которые у тебя уже есть. Они не в сети, ни где-то там, а в памяти у тебя, локально. В ту же самую память ты пишешь результат.

И тебя вылечат, и меня вылечат (c)

Я всё же надеюсь, что ты вылечишься. Это ведь не трудно?

Если мы говорим о c10k, которая имеет отношение только к сокетам и их обработке( т.е. чтении и записи в них), то каких хреном ты пытаешься приплести сюда какую-то обработку данных?

Задача состоит в обслуживании 10к потоков, а в реальных условиях это ведь и обработка данный. c10k problem в классическом варианте, то есть чтении и записи в сокеты, решена овердохуя лет назад. В таком виде смысл имеет уже c10m. Ну вот к примеру: nginx в принципе может обработать 10k соединений, но клиентам нужно что-то да отвечать, и если речь идёт о крупном сервисе, то проблема как раз таки в обработке данных, а не сколько можно разом обработать соединений. Если железо недостаточно мощное и ПО кривое и медленное, то сервер может и раком встать.

vm == virtual memory, я думаю ты далее ты сможешь по ключевым словам погуглить.

И каким боком здесь вылезла virtual memory?

У процесса контекст состоит не только из регистров. Ключевые слова я уже написал. И миф о том, что контекстсвич прям дожопы дорогая операция( как и сисколы) основан именно что на медленным переключением адресных пространств.

Боже, куда тебя несет.

Было сказано:

переключение тредов — это дорогая операция, поскольку ОС должна сохранить изрядное количество регистров текущей нити и восстановить значение регистров для другой нити;

ОС вынуждена сохранять значения регистров при переключении нитей одного процесса? Да или нет?

Дерьмо оно и есть дерьмо, но лучше ничего нет.

А почему дерьмо? Тут дело в синтаксисе или в чём?

ПЫЩЬ ЁПТА

Я в ахуе от топика. Все скатилось в говно.

TL;DR пока потоки рулят

Заглянув сегодня после обеда на ЛОР, я понял, что все пропало. Но лично у меня интерес к проблеме остался, поэтому вечером я начал тыкать палкой в треды и селект. HTTP — это сложно и лениво, поэтому tcp echo server. Пока серверы без шаред стэйта и без локов между потоками (что безусловно на руку потокам).

Тачка — гугл n1-highcpu-4 (4 ядра попугаев и 3.5 Гига). Ошметки кода тут: https://github.com/frolosofsky/c10k. Пока я добрался до 1000 коннектов, чуть дальше нагрузочная тулза начинает доминировать по CPU и памяти, завтра вынесу ее на отдельную машину.

Метод нагрузки: создаем соединение, начинаем беспрерывно слать данные (и принимать), создаем второй, и т.д.:

tcpkali 127.0.0.1:8080 -c 1000 --connect-rate 1000 -m'1234567890qwertyuiop' -T1m --latency-connect --latency-marker 123

На сегодня результаты сильно в пользу потоков. Коннекты устанавливаются почти сразу, данных в сравнении с селектом прокачивается сильно больше (с учетом многоядерности). В случае селекта, у тулзы уходит почти минута на установку тысячи соединений. Возможно я не умею писать селект, или обосрался где-то в non-blocking (тыкните носом!), но уже давно пора спать, завтра в свободное время продолжу разбираться.

select:

Total data sent:     4026.7 MiB (4222314153 bytes); seen 17160) (c=7.1 m=19750.3 ms⁹⁵ᵖ)))
Total data received: 4026.3 MiB (4221912096 bytes)
Bandwidth per channel: 1.126⇅ Mbps (140.7 kBps)
Aggregate bandwidth: 562.913↓, 562.967↑ Mbps
Packet rate estimate: 51458.6↓, 48589.9↑ (3↓, 44↑ TCP MSS/op)
TCP connect latency at percentiles: 7.1/12.7/13.6 (95.0/99.0/99.5%)
Message latency at percentiles: 19750.3/28518.3/30259.1 (95.0/99.0/99.5%)

threads:

Total data sent:     35113.4 MiB (36819083720 bytes); seen 1000) (c=28.3 m=5097.5 ms⁹⁵ᵖ)
Total data received: 35191.0 MiB (36900465589 bytes)
Bandwidth per channel: 9.829⇅ Mbps (1228.6 kBps)
Aggregate bandwidth: 4920.019↓, 4909.169↑ Mbps
Packet rate estimate: 447950.3↓, 425187.7↑ (10↓, 22↑ TCP MSS/op)
TCP connect latency at percentiles: 28.3/39.6/51.6 (95.0/99.0/99.5%)
Message latency at percentiles: 5097.5/8838.3/11315.1 (95.0/99.0/99.5%)

обработка данный
клиентам нужно что-то да отвечать
если речь идёт о крупном сервисе
проблема как раз таки в обработке данных
сервер может и раком встать

Какое отношение весь этот набор скучных тезисов имеет к проблеме c10k? :-) Лол :-) Ты перечислил всего лишь множество обстоятельств (ты же знаешь, что такое обстоятельство из курса школьной программы?) работы клиент-сервера :-) Причём тут 10k соединений - совершенно не ясно :-) Почему не 20k или не 1000k? :-) Лол :-)

Если вы обсуждаете c10k, то и обсуждайте c10k.

Какой смысл в обсуждении c10k без привязки к какой-либо реальной задаче? Проверить возможности сетевого стека конкретной ОС? Неэффективность select-а на большом количестве открытых сокетов?

Какое отношение весь этот набор скучных тезисов имеет к проблеме c10k?

Прямое. Проблема c10k уже давно решена, намного важнее вопрос об обработке данных.

И каким боком здесь вылезла virtual memory?

Действительно, а ты прям про неё и подумал? Ой не ври, балаболка.

Боже, куда тебя несет.

Ну что же ты такой одарённый, объясни мне?

ОС вынуждена сохранять значения регистров при переключении нитей одного процесса? Да или нет?

Выглядит так жалко и так глупо. Бедный человек, мне так печально из-за вас. Не люблю эту несправедливость в отношении способностей.

переключение тредов — это дорогая операция
дорогая операция
дорогая

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

Сохранение регистров и их восстановление, даже из рамы - это копейки. Тем более, если у тебя «медленные клиенты», которые будут тригерить 10500 редов на запрос - что в данном случае будет проблемой? Уж явно не треды.

Тем более сам контекст - это копейки в тасксвиче.

Какой смысл в обсуждении c10k без привязки к какой-либо реальной задаче?

А какой был смысл доказывать возможность генерации строк в компайл-тайме на ущербном цепепе без привязки к какой-либо задаче? :-) Всё равно этим никто пользоваться не будет :-) Лол :-)

Действительно, а ты прям про неё и подумал? Ой не ври, балаболка.

Еще раз: с какого бока здесь вылезла virtual memory? Для его ты ее сюда приплел?

Выглядит так жалко и так глупо.

Еще раз: регистры сохранять надо или нет?

Задача состоит в обслуживании 10к потоков, а в реальных условиях это ведь и обработка данный. c10k problem в классическом варианте, то есть чтении и записи в сокеты, решена овердохуя лет назад.

Неверно. c10k объявило неэффективность подхода тред на коннект и определило, что для решения проблемы нужны другие подходы. Причина проста - убогость процессоров и ОС в те времена.

Изначально, тот балабол, который иницировал срач привёл с10к как пример, где немогут треды. Вернее как подтверждение того, что «более чем на 400 тредах уже всё глохнет».

И смысл в том, что 10к тредов спокойно работают. А про то, что c10k протухло - я сказал сразу. Иди почитай тред-первоисточник.

Ну вот к примеру: nginx в принципе может обработать 10k соединений, но клиентам нужно что-то да отвечать, и если речь идёт о крупном сервисе, то проблема как раз таки в обработке данных, а не сколько можно разом обработать соединений.

Ты способен отличать А от Б?

Обработка соединений никак не относится к обработке данных. Данные ты можешь обрабатывать где угодно и как угодно. Хоть в этих тредах, либо если тебе не нравится - в другом. В подходе с мультиплексингом они так же отделены и так же многопоточны.

А как там там работает твой хттп, пхп и прочее - к теме не имеет отношения. Мало c10k - претензии не ко м не, не я это определил как то, что треды не могут.

Но лично у меня интерес к проблеме остался, поэтому вечером я начал тыкать палкой в треды и селект.

Э...

Если ты готов померять реальный перформанс, пиши, я налабаю на еполле аналоги твоих тестовых серверов

Что-то не сходится. Речь-то шла про epoll изначально.

А если write вернет значение меньше чем n? Может правильнее цикл делать?

epoll будет вишенкой.

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

А почему дерьмо? Тут дело в синтаксисе или в чём?

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

С++ - есть обёртка над Си, который «полностью динамичный язык». В си нет функций. В си вообще нет ничего - всё это лишь интерфейсы к памяти. В си всё динамично. От того в С++ так же нет тех же функций.

Из-за того, что никаких объектов языка в си на уровне языка нет - у тебя есть тысячи проблем с компилтаймом в С++. Нет констекспр-памяти, тех же массивов, либо строк? Правильно - в си нет ни строк ни массивов.

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

struct A { void fa(B b) {b.fb();} void fb() {} }
struct B { void fa(A a) {a.fb();} void fb() {} }

И прочее, и прочее. Мне лениво всё это перечислять.

Что-то не сходится. Речь-то шла про epoll изначально.

Не шла. В очередной раз ты проболаболил.

Не шла. В очередной раз ты проболаболил.

Царь, да ты реально больной придурок:

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

Посмотри в какой теме ты находишься и о чем изначально писал ТС.

И прочее, и прочее. Мне лениво всё это перечислять.

Ага, или вот это

std::unique_ptr<const char> junk("dont touch cepepe");

Еще раз: с какого бока здесь вылезла virtual memory? Для его ты ее сюда приплел?

Тебе объяснили. Все твои мифы, что ты по своей глупости ретранслируешь - это всё со времён форков, когда переключение требовало переключения адресного пространства. То же самое и с сисколами.

Еще раз: регистры сохранять надо или нет?

Ты будешь со мною играть и пытаться меня ловить? Тебе надо ещё лет 50 землю коптить, чтобы хотя бы появилась призрачная надежда поймать текущего меня.

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

Ты на простой вопрос ответить можешь: нужно ли ОС при переключении нитей сохранять регистры? Да или нет?

Посмотри в какой теме ты находишься и о чем изначально писал ТС.

Причём тут то, что писал ТС, либо кто-то ещё? В рамках моей темы никаких епулов не было. А эта тема продолжение моей.

А если ты начинаешь ставить какие-то левые условия, то причём тут царь, который заявлен в топике? Епулы - это блажь ТС"а. И к «изначально» она не имеет никакого отношения.

А по поводу того, что делает ТС - я написал выше. Можешь почитать.

Какое отношение твоя потуга имеет к моему ответу? Выкатывай основании для выката подобных вопросов мне. Нету - слейся и не пытайся юлить.

Причём тут то, что писал ТС, либо кто-то ещё?

При том, что ТС, т.е. staseg изначально говорил про epoll, а промежуточные результаты опубликовал для select-а. О чем я ему и написал. Не тебе, придурок, а ТС-у.

Причём тут то, что писал ТС, либо кто-то ещё? В рамках моей темы никаких епулов не было. А эта тема продолжение моей.

Чувак спросил другого почему решение на селекте, если обещался епол. Другой чувак чотко ответил почему. Это называется дискуссия, мой дорогой друг, то во что ты не умеешь.

Какие есть предпосылки к тому, что врайт вернёт значение меньше чем n?

вот ради этого я и сижу в царетердах, люблю смотреть, как у оппонентов царя начинаются МАНЁВРЫ

Так и запишем: ответа на вопрос, нужно ли ОС сохранять регистры при переключении нитей, Царь не знает.

Не тебе, придурок, а ТС-у.

Женька, на тебя так шаблоны цепепе действуют что-ли? :-) Зачем оскорбляешь собеседника? :-)