в стандарт 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, но уже хотелось чуть быстрее работать.

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

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

кстати я что-то никогда wsgi не дампил, а он точно бинарный?

Есть тупой вопрос. Есть прометей с графаной, на что делать алерт тип сервер не доступен?)

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

но работает она хуево, поэтому мы ставим нджинкс, да? :)

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

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

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

ну это норм.

и типа, пока не отдашь клиенту держишь всё это

я и в питоне так делаю

и в го

да, держу, потому что не хочу это постоянно передергивать.

это ж удобно

ERROR: S client not available

не так.

ты держишь это "взяв" из пула, но уже не используешь

блин ну тут вопрос про то "как пишем"

не, ну если у меня похапешечка, то у меня проблемы.

вспомни php там пока прцоесс не сдох, у нас всё аллоцированно

я про то, зачем это в нормальных языках?

ну а что, на питоне так нельзя написать чтоли ? )

ну а что, на питоне так нельзя написать чтоли ? )

да можно и на баше написать

незачем, кажется что application servers явление 2000-2007

чо уж тут, неткатом общаться с постгресом, то о чем я мечтал

/mi как-то не видел хороших HTTP-серверов на питоне. Зато видел Python GIL

/mi как-то не видел хороших HTTP-серверов на питоне. Зато видел Python GIL

торнадо

sanic ))

App-сервер удобен, для обслуживания гетерогенных сайтов - половина на PHP, половина на Django, и плюс микросервисы на Go там же. Ну, и проще все это через Nginx отдавать и держать в одном конфиге

в чем простота-то?

это ж железка. запустил и она работает)

сложно править 3 конфига вместо одного?

это у тебя архитектурная проблема тогда какая-то, а не сложность:)

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

Простота в том, что Nginx, например, позволяет в разном location показывать разные web-сервисы, чтобы все работало как один сайт

он это позволяет и когда все работает через fastcgi

или проксируется или whatever

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

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

но это обычный нджинкс.

лол

и причем тут "App-сервер" ?)

Зачем обычный nginx все и так знают

Ну, если не нужен uWSGI или fastcgi - не надо исользовать. :) Но по натуре того же питона хороший, производительный web-сервер именно на нем не напишешь.

мне кажется ты не понимаешь о чем говоришь:)

кого не надо использовать если не нужен fastcgi ?:)

что такое "производительный"?:)

думаешь какая-нить махина на джаве типа ibm websphere производительная?:)