Fastest web-scripts (си и wsgi|scgi) [?]
Читай про интеграцию питона с C/C++ модулями и пиши, сколько хочешь, на сях под любой доступный WSGI-враппер
Интуитивно кажется, что на чистом си+fcgi пошустрее будет... А интересует именно fastest way.
fastest waywrite in C, и желательно в кернел-пейсе =)
да, реальная маза: вклиниваешься в драйвер сетевой карты и...
Интересная задумка на отдаленное будущее 
А в контексте VDS, если? Я пока только c+fcgi научился, еще шустрее можно?
p.s. - "Куда тебе еще шустрее?!" - "Незачем что-то делать наполовину хорошо, если все равно делать целиком. А вообще чисто персонально-исследовательские намерения в этом вопросе
"
А в контексте VDS, если? Я пока только c+fcgi научился, еще шустрее можно?
p.s. - "Куда тебе еще шустрее?!" - "Незачем что-то делать наполовину хорошо, если все равно делать целиком. А вообще чисто персонально-исследовательские намерения в этом вопросе
"пеши драйвер телепатии лучше, никакой нахер инет не нужен будет. Хочет юзверь сайтец глянуть, хуякс, и он у него уже в башке.
модули к апачу (или что там у тебя) можно писать
> да, реальная маза: вклиниваешься в драйвер сетевой карты и...
Ты про это?
---
...Я работаю антинаучным аферистом...
Ты про это?
---
...Я работаю антинаучным аферистом...
С давних времен читаю в дискуссиях про скорость web-скриптов, что требовательные к скорости части, следует писать на c/c++, а сходу нашел только c/c++ через cgi (вроде как fastcgi тоже).Модуль Апача пиши.
Если совсем быстро — обращайся, дам свой демон, он быстрый как понос. Специально для быстрых модулей.
А разве java-сервлеты (и ASP.NET?) в большинстве случаев не самые быстрые, не считая модулей апатча и собственных драйверов/веб-серверов? Ну и библиотеки на C/C++ к ним тоже можно подключать, хотя и не без проблем: http://docstore.mik.ua/orelly/java-ent/servlet/ch13_05.htm
А разве java-сервлеты (и ASP.NET?) в большинстве случаев не самые быстрыеЭто пиздец медленные, наверное самое медленное что есть.
дам свой демон, он быстрый как поносhttp://3.rdrail.net/blog/libevent-webserver-in-40-lines-of-c...
код однотрэдовый, кроме того еще и с мемликом. в 40 строчках мемлик оставить это жесть.
ты про evbuffer? не факт что его тут нужно уничтожать руками.
хотя да, рефферес-каунтер на него бросить всё равно надо.
хотя да, рефферес-каунтер на него бросить всё равно надо.
тут он дергает realloc:
evbuffer_add_printf(buf, "Requested: %sn", evhttp_request_uri(req;
а free чтоб вызвалось надо сказать evbuffer_free
evbuffer_add_printf(buf, "Requested: %sn", evhttp_request_uri(req;
а free чтоб вызвалось надо сказать evbuffer_free
думаешь evhttp_send_reply копирует себе буффер?
тут зависит от семантики, если буффер отданный в evhttp_send_reply больше использовать нельзя и она сама его уничтожит когда дошлёт то всё ок. а если она берёт себе ссылку на него — то надо бросать то что есть.
тут зависит от семантики, если буффер отданный в evhttp_send_reply больше использовать нельзя и она сама его уничтожит когда дошлёт то всё ок. а если она берёт себе ссылку на него — то надо бросать то что есть.
и чо что однотредовый?
2:
evhttp_send_reply не копирует себе буффер, она просто пишет его содержимое в сокет, чтоб потом удалить буфер надо вызватьevbuffer_free
да и по логике если вызвал evbuffer_new то логично представить, что надо руками вызвать evbuffer_free потом, это как бэ си-стайл.
2spin: топик называется Fastest web-scripts, я так понимаю важна производительность, все современные процы (тем более серверные) имеют 2 ядра и больше, поэтому я рискнул предположить что однотрэдовый сервер в данном контексте отстой
evhttp_send_reply не копирует себе буффер, она просто пишет его содержимое в сокет, чтоб потом удалить буфер надо вызватьevbuffer_free
да и по логике если вызвал evbuffer_new то логично представить, что надо руками вызвать evbuffer_free потом, это как бэ си-стайл.
2spin: топик называется Fastest web-scripts, я так понимаю важна производительность, все современные процы (тем более серверные) имеют 2 ядра и больше, поэтому я рискнул предположить что однотрэдовый сервер в данном контексте отстой
http_send_reply работает асинхронно и в сокет сразу всё может и не влезть
ok, был неправ, действительно копирует. удалять все равно нужно)
если мы не знам число сетевух в сервере, есть риск получить обратный результат
межпроцессные взаимодействия могут убить бОльшую часть выгоды от нескольких процов, особенно если они совместно качают через одну общую дырочку
ЗЫ: Конечно же, я тут предполагаю, что сетевые взаимодействия - самое узкое место в данном сервере. Например, если нужно обрабатывать 20 тысяч запросов, а-ля тупого ответа "200 OK", в секунду. Если же нужно долго обрабатывать каждый запрос, конечно, треды нужны, но уже не на сетевой части.
межпроцессные взаимодействия могут убить бОльшую часть выгоды от нескольких процов, особенно если они совместно качают через одну общую дырочку
ЗЫ: Конечно же, я тут предполагаю, что сетевые взаимодействия - самое узкое место в данном сервере. Например, если нужно обрабатывать 20 тысяч запросов, а-ля тупого ответа "200 OK", в секунду. Если же нужно долго обрабатывать каждый запрос, конечно, треды нужны, но уже не на сетевой части.
еще раз.
топик называется fastest блаблабла. Я так понимаю есть какое-то CPU-bound приложение (иначе не было бы слов C++/C, fastest которое должно обмениваться чем-то по http.
Под одной маленькой дырочкой я так понимаю ты подразумеваешь сеть? И поэтому там речь о количестве сетевух? (это я вообще слабо понял как относится к теме)
В общем если речь идет о CPU-bound приложении, то логично использовать все ядра современных процов. Понятно, что это надо делать грамотно.
В контексте либэвента видимо проще всего забиндить сокет 1 раз, а потом добавить в event-loopы всех трэдов (по числу ядер как правило) accept этого дескриптора.
Демон пианиста *наверное* все это делает. А урезанный кусок кода присланный бачаном - нет.
ЗЫ. Пока отвечал spin уже тоже пост подправил. В случае когда сеть боттлнек вообще практически пофиг на чем писать)
топик называется fastest блаблабла. Я так понимаю есть какое-то CPU-bound приложение (иначе не было бы слов C++/C, fastest которое должно обмениваться чем-то по http.
Под одной маленькой дырочкой я так понимаю ты подразумеваешь сеть? И поэтому там речь о количестве сетевух? (это я вообще слабо понял как относится к теме)
В общем если речь идет о CPU-bound приложении, то логично использовать все ядра современных процов. Понятно, что это надо делать грамотно.
В контексте либэвента видимо проще всего забиндить сокет 1 раз, а потом добавить в event-loopы всех трэдов (по числу ядер как правило) accept этого дескриптора.
Демон пианиста *наверное* все это делает. А урезанный кусок кода присланный бачаном - нет.
ЗЫ. Пока отвечал spin уже тоже пост подправил. В случае когда сеть боттлнек вообще практически пофиг на чем писать)
вообще-то, не факт что раз С++, это сразу CPU-bound 
Может, человеку нужен демон, который как раз элементарные запросы должен обрабатывать, но БЫСТРО?
Например, 10тыщ раз в секунду отдавать пять килобайт динамических данных
Или отвечать в среднем 0.1мс на любой запрос
При таких требованиях апач отпадает сразу, время ответа большое и вообще неповоротлив.
Лайт-хттпд - тоже не особо-то быстрый в этом плане...
nginx - на нём не всё можно написать
ну вот в сущности отсюда и мог произрастать вопрос топикстартера, хотя кто знает
PS: при таких требованиях пара-тройка подобных демонов забъёт гигабитку только в путь
PPS: перечитал вопрос топикстартера и что-то уже не уверен, что я правильно его понял
Может, человеку нужен демон, который как раз элементарные запросы должен обрабатывать, но БЫСТРО?
Например, 10тыщ раз в секунду отдавать пять килобайт динамических данных
Или отвечать в среднем 0.1мс на любой запрос
При таких требованиях апач отпадает сразу, время ответа большое и вообще неповоротлив.
Лайт-хттпд - тоже не особо-то быстрый в этом плане...
nginx - на нём не всё можно написать
ну вот в сущности отсюда и мог произрастать вопрос топикстартера, хотя кто знает
PS: при таких требованиях пара-тройка подобных демонов забъёт гигабитку только в путь
PPS: перечитал вопрос топикстартера и что-то уже не уверен, что я правильно его понял
Может, человеку нужен демон, который как раз элементарные запросы должен обрабатывать, но БЫСТРО?ну точно kernel space драйвер нужен
> ну точно kernel space драйвер нужен
Есть мнение, что для этого совсем не обязательно лезть в ядро,
можно просто посылать готовые IP пакеты через особые сокеты
или задействовать BPF.
---
"Для того, чтобы не пройти мимо цели, иногда необходимо пойти ко дну."
Есть мнение, что для этого совсем не обязательно лезть в ядро,
можно просто посылать готовые IP пакеты через особые сокеты
или задействовать BPF.
---
"Для того, чтобы не пройти мимо цели, иногда необходимо пойти ко дну."
Оставить комментарий
feliks28
С давних времен читаю в дискуссиях про скорость web-скриптов, что требовательные к скорости части, следует писать на c/c++, а сходу нашел только c/c++ через cgi (вроде как fastcgi тоже).А через wsgi или scgi можно как-то?