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

вижу, что с++17 это не стандарт, а draft

Всем насрать. Это стандарт, а то что он draft - из этого ничего и не следует. Ты другого и не видел.

Поэтому и компилятору и всем остальным нсрать на твои потуги.

при этом не осилившего написать хоть какой-нибудь серьвер

Почему я должен ради какой-то макаки вроде тебя писать сервер?

В новое ты так же не можешь.

В новое ты так же не можешь. Там же просто понатыкано использование экспериментальных фич ради использования этих фич. Это не и не код на C++, и не код на C.

А ещё ты не можешь в чуть более сложную логику. Ты просто вчитываешься в статейки про новые фичи C++, ведь тебе не хватает скилов освоить что-то ещё. В итоге у тебя hello-world'ы, которые не могут делать ничего. Написать реверс-прокси ты не осилил. Это же надо немного подумать. Гораздо проще написать простыню текста и выкатить наспех написанный кривой эхо-сервер. Там нет логики. Принял-отправил.

Неужели ты думаешь, что этим сможешь кого-то обмануть?

Царь, ты только мне додумался прислать письмо «щастя», начинающееся со слов:

У меня к тебе есть прямой вопрос. И я прошу на него промой ответ.

Отсутствие вменяемости с твоей стороны на лоре связано с боязнью признать царя, либо просто с общей неадекватностью

Или только я удостоин такой чести?

Тебе бы к врачу.

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

Или только я удостоин такой чести?

Огорчу тебя, но нет, не ты первый, не ты последний. Мне тоже «давали шанс», где-то с неделю назад, не помню точно. Код присылал, тот же самый, непричёсанный.

Интересно, кому ещё?

неверно

Пардон, пропустил. У ТС точка зрения Царя подтверждается.

и тестанул его

И как результаты? Может еще устраивающую, например eao197 обработку данных добавишь?

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

Я надеюсь, все кому интересно, подключаться и внесут конструктива.

Так то я все темы достаточно внимательно прочитал(:

Так то я все темы достаточно внимательно прочитал(:

Ты бы лучше код написал. Утменя пока что ab не может тест завершить. Из 20000 запросов при concurrency 10000 порядка сотни отваливаются.

Интересно, кому ещё?

мне еще царек давал шанс :-) кажись вчера истек или сегодня

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

царек начал гуглить, нашел мои посты (с кодом) на лоре 2013 года по теме рандомного прохода по памяти, где я писал «у меня должно быть 20МT/c а реально получается 15МТ/с», и вывод сделал точно царский — потрясающе альтернативно одаренный — что это типа лаба и я ее хочу за его счет халявно сделать

после этого он стал давать мне шанс

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

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

уникальной альтернативной адекватностью

хороший термин, надо запомнить

Никто еще на гитхаб не кинул проект? Вот это тот самый источник боли и вдохновения: https://godbolt.org/g/VVQnGb ?

И как результаты?

«тестанул» это не протестировал, а разок запустил

но уже видно, что проверять значения read надо, т.к. даже 8 байт могут читаться кусками

Может еще устраивающую, например eao197 обработку данных добавишь?

шансы есть (но маленькие)

меня больше интересуют basics — ну то есть сколько отожрут tlb cache misses и в том же духе

Мне не особо интересен эхо-сервер. Интересен реверс-прокси, где будет много read-write на соединение, потому что соединения медленные. Своё пока не выкладывал, потому что есть только вариант на тредах, но нет варианта на событиях. Не с чем сравнивать.

Вот это тот самый источник боли и вдохновения: https://godbolt.org/g/VVQnGb

Вроде как это код Царя, да.

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

AAAAAAAAAAAAA

1K MD5 client, server.

Писал на основе кода Царя. Надеюсь, он меня сильно не побьет.

Клиент генерит 1К рандомных байт, шлет серверу в 10000 потоков, тот считает md5, копипастит до 1К байт и шлет в ответ. Клиент проверяет.

Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz

Клиент отрабатывает за 0.4..0.5 с.

htop очень мило показывает VIRT 80.1G (=

Это же опять эхо-сервер.

Я делал реверс прокси, который принимает от клиента запрос, пересылает его на бекенд, а потом перекачивает ответ бекенда клиенту. Бекенд сравнительно медленный. Чтобы ждать поменьше, поставил бекендом Nginx, который отдаёт файл размером 163840 байт с ограничением в 8192 байта в секунду. Это 20 секунд в идеальном случае. С очень большой вероятностью при запросе в 10000 потоков все 10000 соединений будут работать одновременно.

А теперь рассмотрим твой эхо сервер. Он получает 1 КБ данных, сразу шлёт 1 КБ ответ. Сколько по времени обрабатывается одно соединение? Я думаю, это будет достаточно быстро: миллисекунда и меньше. А сколько соединений обрабатывается одновременно? Если их на диаграмме Гантта нарисовать, они такой лесенкой выстроятся. Одновременно будет не так уж и много.

Допустим, они все выстроились равномерно. Каждый запрос отдельно обрабатывается за 1 мс, а все проходят за 0,4 с. Если время старта размазано равномерно, каждый следующий запрос стартует через 0,4/10000 = 4e-5 с. Стало быть, за время обработки одного запроса, 1e-3 с, будет начата обработка ещё 1e-3/4e-5 = 25 запросов. Итого одновременно обрабатывается около 25 запросов. А если запрос обрабатывается быстрее 1 мс, то concurrency ещё меньше.

В итоге у меня вопрос. Что именно ты пытался измерить?

я думаю, стоит выставить в условие «не менее 10К активных нитей» (для чего в клиенте напихать microsleep или еще может чего, у меня нет хороших идей)

стоит выставить в условие «не менее 10К активных нитей»

Царь против будет. Условие изменяется, всё такое. :-D

У вас тут другие развлечения. А в моём условии эти 10к нитей вынуждены были быть активны, без всяких sleep'ов и тому подобных. Тормозит трафик специальный конфиг Nginx'а. А в качестве клиента у меня ab (Apache Benchmark). Он наоборот, старается сделать запросы побыстрее.

#define PCKT_SZ 1024

1. ты видимо сишник; тогда будь добр, убери к чертям этот говнокласс worker и напиши код на вызовах обычных pthreads — это будет и короче, и яснее

2. почему у тебя memcpy в цикле do while, а не for?

3. если из сокета прочитать не удалось, то диагностики нет — это видимо неправильно

Царь против будет. Условие изменяется, всё такое. :-D

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

анонимусы заблочились по порогу 1К мессаджей

А я-то думаю, чего это Царь не ответил? Нехорошо получилось.

Я делал реверс прокси

Ждем код.

Что именно ты пытался измерить?

Ничего.

Я не могу понять, ты хочешь опровергнуть утверждение, что c10k не проблема для современного железа, сравнить c10k на pthread vs epoll/select на какой-либо задаче(задачах) или подобрать задачу, на которой на 10k подлючений машина гарантированно ляжет?

А я-то думаю, чего это Царь не ответил? Нехорошо получилось.

безответность это да, не хорошо, но с другой стороны за весь разговор царь в своем коде только и сделал, что заменил ";;" на ";"

Я не могу понять, ты хочешь опровергнуть утверждение, что c10k не проблема для современного железа, сравнить c10k на pthread vs epoll/select на какой-либо задаче(задачах) или подобрать задачу, на которой на 10k подлючений машина гарантированно ляжет?

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

в реальном мире сеть тормозит и теряет пакеты — с этим ты согласен?

Ждем код.

Не готов вариант на epoll, так что сравнивать не с чем.

сравнить c10k на pthread vs epoll/select на какой-либо задаче(задачах)

Вот это. Задача была — HTTP реверс-прокси. Мне интересно, как это будет работать на тредах, когда ляжет. И когда ляжет вариант на epoll.

1. Наверно больше да, хотя С++ тоже могу немного. Лень переписывать, честно(= Да и времени особо нет, это на неделю затянется.

2. Правил какой то кусок, лень все переписывать.

3. Ну так то да, но это ж proof-of-concept говнокод. А надо еще на epoll сделать, потом вариант с JSON какой-нибудь наваять. Еще хочу попробовать libmicrohttpd, они обещают our different threading models (select, poll, pthread, thread pool).

Вот это. Задача была — HTTP реверс-прокси. Мне интересно, как это будет работать на тредах, когда ляжет. И когда ляжет вариант на epoll.

а можно его сделать попроще? чтоб не парсить хттп, а тупо читаем-пишем байты в обе стороны, и все?

2. Правил какой то кусок, лень все переписывать.

(тяжелый вздох) тяжело на этот код смотреть, особенно на говнокласс

мне не лень код чуток причесать — вопрос только в том, чтобы ты считал результат своим кодом, а не как царь

а можно его сделать попроще? чтоб не парсить хттп, а тупо читаем-пишем байты в обе стороны, и все?

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

мне не лень код чуток причесать — вопрос только в том, чтобы ты считал результат своим кодом, а не как царь

В смысле? Изначально код Царя, я лишь добавил немного работы.

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

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

По хорошему, нужно брать пресловутый nginx, научить его работать с 10000 pthread-ов и проверять на большом количестве разных серверов.

Максимализм какой-то. Написать самому два варианта прокси будет проще, чем переделывать Nginx. Работа на событиях сильно отличается от работы в треде на блокирующих вызовах. Да, формально можно преобразовать колбеки в блокирующие вызовы, но для этого придётся разобраться во всех деталях работы. Видимо, ты слабо представляешь себе объём работы.

я лишь добавил немного работы.

А смысл?

Кстати, я выложил текущую версию кода прокси на нитях: https://github.com/i-rinat/c10k-benchmark-fixture. (/cc www_linux_org_ru)

А смысл?

Ну я же не спрашиваю, в чем смысл в 10000 потоков тянуть файл ``длиной 8192000 байт с ограничением скорости в 8192 байта в секунду".

glib-2.0 в зависимостях это покруче gcc7.

Ну я же не спрашиваю

В этом и проблема. Не спрашиваешь. Просто увидел, что в треде упоминалось «добавить работы» и бездумно добавил, не задавшись вопросом: «а зачем? Что это даст?»

glib-2.0 в зависимостях это покруче gcc7.

Ага, сравнил.

Интересно, много ли есть дистрибутивов, в которых нет glib-2.0?

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

код твой смотрю — туда явно просится define на тему == -1

явно просится define на тему == -1

Эээм, нет, спасибо. Строчку экономить, что ли?

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

Нет.

Я конечно не царь, но у меня есть сомнения насчет эффективности этого кода. Зачем заводить отдельную строку для хедеров, если и так уже выделили 16К на стеке? Все потоки побегут дружно ломится в маллок и сядут там на мьютекс. Тот же nginx по умолчанию выделяет только 2К на хедеры.

Только заметил что и hp_new тоже выделяет память.

Я ж не Царь, делал как попроще было. Да и цель не была в том, чтобы с nginx соревноваться. Я хочу сравнить два подхода: «один тред на всё» против «по треду на соединение».

Тот же nginx по умолчанию выделяет только 2К на хедеры.

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

Понятное дело, что в nginx оптимизируются разные варианты, в том числе и случай множества мелких запросов. Но у меня запросов два раза по десять тысяч. За 20-30 секунд работы. Усложнение кода стоит того?

Все потоки побегут дружно ломится в маллок и сядут там на мьютекс.

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

да, точно, малые аллокации же попадут в TLS.

Эээм, нет, спасибо. Строчку экономить, что ли?

там строчек 20 должно сократиться, но не в этом дело

а тебе нравится Офигенно Творческая Работа придумывать текст сообщения об ошибке, когда в си есть препроцессор и стрингификация (а так же __FILE__ и __LINE__) ?

свой текст сообщения об ошибке должен быть тогда, когда он несет новую информацию; вот (слегка поломанный) пример: в ответ на fopen == NULL напечатать «вставьте диск в cd/dvd дисковод»

да, точно, малые аллокации же попадут в TLS.

я про них другое вспоминаю (хотя не факт что верно): они аллоцируют/удаляют большие блоки действительно через мьютекс, а затем малые блоки аллоцируют/удаляют уже без мьютекса

т.е. их все равно настроить надо, чтобы они понимали, что значит большие и маленькие — а так как тредов у нас овер9000, то это может быть критично

ну и вообще я за размещение на стеке, несмотря на все вышесказанное (меньше tlb миссов)

Спасибо, конечно. Но вместо вылизывания кода варианта на нитях я лучше займусь реализацией варианта на epoll.

Что, код у меня настолько страшный? ☺

Царю:

это ты или не ты ?

Царю:

?

Оокей, лэтс ду зе маф. Кажется, я доделал вариант на epoll. Настало время сравнить. Код лежит вот тут: https://github.com/i-rinat/c10k-benchmark-fixture. Нагружаю с помощью Apache Benchmark в 10 тысяч потоков. Делается 20 тысяч запросов. Бекендом стоит Nginx с ограничением скорости отдачи в 8192 байта в секунду. Запрашивается файл длиной 163840 байт. В идеале каждый запрос будет длиться 20 секунд.

Вариант на нитях:

$ time ./server_threads
real	2m12,089s
user	0m0,467s
sys	0m22,957s

(Время real имеет мало смысла — я отключаю программу по Ctrl-C.)

$ time ab -c 10000 -n 20000 http://127.0.0.1:65001/163840.html
This is ApacheBench, Version 2.3 <$Revision: 1796539 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Completed 20000 requests
Finished 20000 requests


Server Software:        nginx/1.12.0
Server Hostname:        127.0.0.1
Server Port:            65001

Document Path:          /163840.html
Document Length:        163840 bytes

Concurrency Level:      10000
Time taken for tests:   112.232 seconds
Complete requests:      20000
Failed requests:        1875
   (Connect: 0, Receive: 0, Length: 1875, Exceptions: 0)
Total transferred:      2979000168 bytes
HTML transferred:       2974679040 bytes
Requests per second:    178.20 [#/sec] (mean)
Time per request:       56115.935 [ms] (mean)
Time per request:       5.612 [ms] (mean, across all concurrent requests)
Transfer rate:          25921.16 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   73  73.0     27     205
Processing: 18043 29848 26368.6  19129  112008
Waiting:        0 2603 8476.9     14   56719
Total:      18046 29921 26388.4  19273  112184

Percentage of the requests served within a certain time (ms)
  50%  19273
  66%  20498
  75%  21187
  80%  23588
  90%  73826
  95%  107990
  98%  112138
  99%  112154
 100%  112184 (longest request)

real	1m52,270s
user	0m0,597s
sys	0m4,995s

Версия на epoll:

$ time ./server_epoll
real	1m24,830s
user	0m0,272s
sys	0m10,280s

$ time ab -c 10000 -n 20000 http://127.0.0.1:65001/163840.html
This is ApacheBench, Version 2.3 <$Revision: 1796539 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Completed 20000 requests
Finished 20000 requests


Server Software:        nginx/1.12.0
Server Hostname:        127.0.0.1
Server Port:            65001

Document Path:          /163840.html
Document Length:        163840 bytes

Concurrency Level:      10000
Time taken for tests:   43.341 seconds
Complete requests:      20000
Failed requests:        0
Total transferred:      3281560000 bytes
HTML transferred:       3276800000 bytes
Requests per second:    461.45 [#/sec] (mean)
Time per request:       21670.632 [ms] (mean)
Time per request:       2.167 [ms] (mean, across all concurrent requests)
Transfer rate:          73939.89 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  702 831.0    187    3054
Processing: 18264 19354 406.3  19340   22418
Waiting:        1  267 329.2    235    3361
Total:      18797 20056 886.4  19782   23435

Percentage of the requests served within a certain time (ms)
  50%  19782
  66%  20136
  75%  20299
  80%  20500
  90%  21759
  95%  22177
  98%  22326
  99%  22570
 100%  23435 (longest request)

real	0m43,397s
user	0m0,532s
sys	0m5,649s

И контрольный замер самого бекенда на Nginx:

$ time ab -c 10000 -n 20000 http://127.0.0.1:8080/163840.html
This is ApacheBench, Version 2.3 <$Revision: 1796539 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Completed 20000 requests
Finished 20000 requests


Server Software:        nginx/1.12.0
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /163840.html
Document Length:        163840 bytes

Concurrency Level:      10000
Time taken for tests:   43.911 seconds
Complete requests:      20000
Failed requests:        0
Total transferred:      3281560000 bytes
HTML transferred:       3276800000 bytes
Requests per second:    455.47 [#/sec] (mean)
Time per request:       21955.417 [ms] (mean)
Time per request:       2.196 [ms] (mean, across all concurrent requests)
Transfer rate:          72980.81 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  530 778.3    144    3053
Processing: 18149 19371 511.0  19404   21534
Waiting:        0  144 293.9     66    3413
Total:      18185 19901 953.9  19843   23946

Percentage of the requests served within a certain time (ms)
  50%  19843
  66%  19852
  75%  20149
  80%  20342
  90%  20798
  95%  22171
  98%  22658
  99%  23032
 100%  23946 (longest request)

real	0m43,964s
user	0m0,369s
sys	0m4,933s

Тестил на ноутбучном i7-6820HQ CPU @ 2.70GHz, 4C8T, без турбобуста, powersave.

deadskif, PtiCa, eao197, www_linux_org_ru, staseg. Кому интересно было, что произойдёт? Если ещё кого-то забыл, позовите.

В общем, у меня вышло так, что вариант реверс-прокси на нитях из 20000 запросов поломал 1875 (частично). 9% повреждений не то чтобы совсем катастрофа, но уже провал. Вариант на epoll прокачал через себя всё, в два раза быстрее, не потеряв ничего. Ну как в два раза быстрее. Он не внёс ощутимых задержек по сравнению с тестированием самого Nginx-бекенда. Это на localhost.

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

Большое спасибо!