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

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

парсинг HTTP - простая задача. миллион запросов в секунду - это не заоблачное что-то.

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

Там куда больше проблем доставит тюнинг сети

парсинг HTTP - простая задача. миллион запросов в секунду - это не заоблачное что-то.

миллион rps не заоблачный показатель?

расскажите, как вы безпроблемно обслуживаете 1m rps, с удовольствием послушаю

миллион rps не заоблачный показатель?

Вопрос в количестве 500ок же ;)

миллион rps не заоблачный показатель?

Если ты отвечаешь 200ок на все, то реализуемо

расскажите, как вы безпроблемно обслуживаете 1m rps, с удовольствием послушаю

я про парсинг и реализацию протокола, а вы мне про приложение и бизнес логику

ну с nginx можно в таком случае еще больше получить производительность отдавая 444

@wavedocs я не сильно заморачиваясь на тюнинг пару лет назад на более-менее обычном железе получал 500к рпс http, именно на отдачу "200 ок", но с полным парсингом и валидацией запроса

Вопрос в количестве 500ок же ;)

отдать 1мрпс 500ок тоже непросто. но возможно.

ну с nginx можно в таком случае еще больше получить производительность отдавая 444

это не http

если заморочиться тюнингом дальше и взять железо чуть пожирнее 2-х 8и ядерных процов, то можно и больше на nginx'е

это не http

c чего бы?

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

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

c чего бы?

ответ отсутствует.

ответ отсутствует.

но протокол то юзается http

но протокол то юзается http

tcp

444 Connection Closed Without Response A non-standard status code used to instruct nginx to close the connection without sending a response to the client, most commonly used to deny malicious or malformed requests.

@wavedocs https://camo.githubusercontent.com/6958e5269df87068b510116c6f9028ed28d33419/687474703a2f2f692e6779617a6f2e636f6d2f61383563313864333136326466623436623438356262343165306164343433612e706e67

я просто оставлю это тут

если конфиг типа server { listen 80 default_server return 444; } и это единственный сервер, я почти уверен что нджинкс не парсит ничего.

именно к вопросу парсинга http

444 Connection Closed Without Response A non-standard status code used to instruct nginx to close the connection without sending a response to the client, most commonly used to deny malicious or malformed requests.

"non-standard" ничего не говорит?

в стандарт http не входит, но с клиентом общение идет по http протоколу

бенчмарк как я понимаю 2014 года, 5.4М запросов в секунду может перелопатить парсер

в стандарт http не входит, но с клиентом общение идет по http протоколу

там общение >syn <synack >ack >GET /blablabla\nHost:blablabla.... <rst

тут нет HTTP

а GET это что?:)

tcp :D

ааа ок

а GET это что?:)

tcp же

а GET это что?:)

пока нет ответа - это все еще чистый tcp

все эе очевидно

а о чем вы кстати спорите?:)

а о чем вы кстати спорите?:)

хз

мне говорят что протокол сложный, я говорю что простой

а как сервер узнает что надо 444 отдать?

а о чем вы кстати спорите?:)

о том что uwsgi нужен потому что http парсить сложно и дорого и медленно (по словам @wavedocs )

а как сервер узнает что надо 444 отдать?

по паре ip:port, я уточнил.

не смотрит в request ?)

поэтому нужны application server'ы

а потом мы ушли в "а насколько просто обработать 1М http requests/s"

пожалуй это неправда

а вы википедию уже читали?

https://en.wikipedia.org/wiki/Application_server держите

и вот дошли до того что отдавать "200 ОК" на любой запрос это не честно, так можно уйти в отправку "444"

о том что uwsgi нужен потому что http парсить сложно и дорого и медленно (по словам @wavedocs )

Как правило для более легкого маштабирования, общего апи. К примеру uwsgi не просто реализация вебсерера но и общение приложения происходит по протоколу wsgi в бинарном виде, тем самым уменьшается латенси, увеличивается скорость обработки запросов

Как правило для более легкого маштабирования, общего апи. К примеру uwsgi не просто реализация вебсерера но и общение приложения происходит по протоколу wsgi в бинарном виде, тем самым уменьшается латенси, увеличивается скорость обработки запросов

http/2?

uwsgi это такой же протокол как fastcgi или http

никакой разницы нет

парсить их одинаково

пожалуй это неправда

ты прав

парсить их одинаково

я об этом же.

Вы тут опять абстрактных коней в вакууме решаете? :)

провел тест, действительно нджинкс парсит HTTP перед тем как "отдать" 444.

Как правило для более легкого маштабирования, общего апи. К примеру uwsgi не просто реализация вебсерера но и общение приложения происходит по протоколу wsgi в бинарном виде, тем самым уменьшается латенси, увеличивается скорость обработки запросов

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

@spuzirev чтобы не морочится с мультипликацией на стороне application и не имплементить логику сто раз

@spuzirev чтобы не морочится с мультипликацией на стороне application и не имплементить логику сто раз

http/2 же?

взял библиотеку и юзаешь

не

есть под почти любой язык

да. сейчас да

зачем unit в 2к17 я ваще хз

ну так nginx app server тока ща анонсировали

я про далёкие 2002

и вопрос о том нафига

и вопрос о том нафига

если верить разработчикам он еще быстрее и проще, чем обычный nginx

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

как по факту, хз

я про unit если что)

@spuzirev чтобы не морочится с мультипликацией на стороне application и не имплементить логику сто раз

нууу, хз, разница обычно между чем-то fastCGI.ListenAndServe() и http.ListenAndServe()

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

вопрос вообще зачем.

почему например мы не запускаем go в uwsgi? :)

нууу, хз, разница обычно между чем-то fastCGI.ListenAndServe() и http.ListenAndServe()

так тебе прид1тся тредик написать с буферизацией, сделать слой для "медленных клиентов"

почему например мы не запускаем go в uwsgi? :)

надо исправить!!!

так тебе прид1тся тредик написать с буферизацией, сделать слой для "медленных клиентов"

а, я понял.

это придумали когда был CGI, но уже хотелось чуть быстрее работать.