А если клиентов много. То переключение контекстов. Либо если евент луп -- reader starwation

сервера быстрые, хочешь сказать?

я не говорил что медленный быстрый или говно

тогда что ты говорил вообще?

Базару ноль, только он пишет в память, а репликация и сохранение на диск в отдельных тредах.

False.

А если клиентов много. То переключение контекстов. Либо если евент луп -- reader starwation

А еще. Если ответики мелкие, то и пакеты мелкие. И всё. Пяка.

тогда что ты говорил вообще?

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

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

в каком смысле упертость? я тебе указал на ошибку в определении

уж на что я не любитель го, но ты, извини, был неправ

8-байтный ответ, Карл

8-байтный ответ, Карл

уходи, извращенец

8-байтный ответ, Карл

вот, наверное, как-то так Даниэль и меняет rps на серверах

Завези мне в него нормальные библиотеки, эксепшны и синтаксис - с удовольствием

про библиотеки ты вроде как-то говорил, что на Го просто смотрел года два назад последний раз

про библиотеки ты вроде как-то говорил, что на Го просто смотрел года два назад последний раз

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

уходи, извращенец

Это самый суровый режим типа. В других очевидно рпс будет меньше и видимо упрется в скорость среды

Есть. Если только не гигантскими шматами

На самом деле нет :)

Они там в темпесте упоролись и написали свой парсер хттп еще быстрее с их слов чем у нгинкса

На самом деле нет :)

Подробнее ?

а у нгинкса не особо быстрый

он быстр overall, но отнюдь не экстремально

Подробнее ?

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

а у нгинкса не особо быстрый

Да ну уж ладно. А у кого быстрее ? И полностью по рфц при том ?

Провести эксперимент с любым кейсом. В качестве сетевой среды использовать локалхост.

Плохой вариант. Не надо использовать лупбэк для таких тестов

потому что он нарезается на пакеты так или иначе

Плохой вариант. Не надо использовать лупбэк для таких тестов

тоже верно

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

Вляет. Чтобы отправить один шмот требуется один сисколл. Со всеми вытекающими

Вляет. Чтобы отправить один шмот требуется один сисколл. Со всеми вытекающими

а, ты про клиент говоришь?

отдать 40 гбит ответами по 100 байт сложно, не буду спорить.

Можно :) writev же

Да ну уж ладно. А у кого быстрее ? И полностью по рфц при том ?

по каким из? :) написать парсер http 1.0 и отдаватор 200 ок - не велика задача.

а, ты про клиент говоришь?

Без разницы

Без разницы

огромная разница

Можно :) writev же

Ага. Для хттп.

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

по каким из? :) написать парсер http 1.0 и отдаватор 200 ок - не велика задача.

Нифига. Я писал.

Нифига. Я писал.

h2o как минимум быстрее

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

А еще. Если ответики мелкие, то и пакеты мелкие. И всё. Пяка.

Не проблема.

И др.

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

1.0 очень простой как протокол.

Кароче. Есть у кого пруфы на то что некий вебсервер с полтычка засатуратил 40 гигабитный линк мелкими ответами ?

1.0 очень простой как протокол.

Не совсем. Это только кажется.

Ну. Если заголовки парсить не надо то да

Подробнее ?

Кусочков может быть много мелких, но главное чтобы в один сокет

Кусочков может быть много мелких, но главное чтобы в один сокет

Ну так это не кейс отдачи ответов по хттп. За исключением если есть пайплайнинг

Кароче. Есть у кого пруфы на то что некий вебсервер с полтычка засатуратил 40 гигабитный линк мелкими ответами ?

Ну, на каком-нибудь onload - вполне возможно

Согласен. На нетмапе или дпдк реально канает

Ну так это не кейс отдачи ответов по хттп. За исключением если есть пайплайнинг

так epoll на каком уровне работает?

Или же dpdk + сетевой стек в юзерленде

так epoll на каком уровне работает?

Кроме как на уровне плинтуса -- ответить умнее не могу

Кроме как на уровне плинтуса -- ответить умнее не могу

на сетевом он работает

но ты поверх него можешь запустить TCP, который нарежет на пакеты все, что ты в сокет запишешь

большими кусками, маленькими - без разницы

это просто байты

Эээ

и где я неправ? ну да, вызов write() заблокирует

если большое передать туда что-то

Ээ

но в асинхронном клиенте это и так понятно

Вообще-то нет

Вообще-то нет

Роман, что я неправильно написал?

поправь

пожалуйста

Для начала начал прочитайте про проблему 10к соединений. Осознайте реальную проблему. Потом прочитайте почему придумали дпдк и нетмап.

Для начала начал прочитайте про проблему 10к соединений. Осознайте реальную проблему. Потом прочитайте почему придумали дпдк и нетмап.

10к решили гораздо легче

Для начала начал прочитайте про проблему 10к соединений. Осознайте реальную проблему. Потом прочитайте почему придумали дпдк и нетмап.

я знаю про проблему 10к соединений, я про нее статью писал. И знаю, как работает epoll

и чем он отличается от poll/select/etc

я знаю про проблему 10к соединений, я про нее статью писал. И знаю, как работает epoll

Отлично. А теперь представь что клиентов реально 10к. И все активно пишут либо читают

Отлично. А теперь представь что клиентов реально 10к. И все активно пишут либо читают

и это через еполл отлично работает.

Роман, что я неправильно написал?

Что будет если ты попробуешь записать в сокет файл на 1гб?

Отлично. А теперь представь что клиентов реально 10к. И все активно пишут либо читают

отлично, и? у нас будет дофига файловых дескрипторов и еполл поверх них

и это через еполл отлично работает.

Не отлично. В плане задержек

Что будет если ты попробуешь записать в сокет файл на 1гб?

зависит от того, синхронный сокет или нет

Не отлично. В плане задержек

ну так epoll же не poll

Не отлично. В плане задержек

10к - не то число на котором начинаешь что-то замечать здесь.

там события, а не линейный пробег

10к - не то число на котором начинаешь что-то замечать здесь.

и да, двачую

10к - не то число на котором начинаешь что-то замечать здесь.

Да ну уж ладно. Пока обработка 9999 клиентов идет, один ждёт

Да ну уж ладно. Пока обработка 9999 клиентов идет, один ждёт

на еполле? нет

там события, а не линейный пробег

Когда все активны линейный пробег будет в твоём приложении. А не в едре.

еполл может миллионы клиентов одновременно держать

Для начала начал прочитайте про проблему 10к соединений. Осознайте реальную проблему. Потом прочитайте почему придумали дпдк и нетмап.

10к уже неактуально.

Да ну уж ладно. Пока обработка 9999 клиентов идет, один ждёт

каждый клиент получает свою порцию данных по очереди. event-loop не должен занимать слишком уж много времени. но он и не занимает. на 10к.

10к уже неактуально.

+++

10к было проблемой для префорка

Когда все активны линейный пробег будет в твоём приложении. А не в едре.

в приложении будут коллбэки на системные события просто

Когда все активны линейный пробег будет в твоём приложении. А не в едре.

каждому по 4к байт, всего 40 мбайт данных. в памяти. миллисекунды.

каждый клиент получает свою порцию данных по очереди. event-loop не должен занимать слишком уж много времени. но он и не занимает. на 10к.

Нутак если надо парсить протокол то это не выполняется

зависит от того, синхронный сокет или нет

O_NONBLOCK

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

что я написал не так?

Ой всё.

Ой всё.

не ой все

а простой wrk

O_NONBLOCK

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

Ой всё.

это твой аргумент?