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