Для меня это была интересная статья.
Хотя бы теперь понятна принципиальная разница между apache и nginx.
Но у меня другой вопрос. А что если сделать аппаратный http сервер? Можно например зашить логику http сервера в ПЛИС. Я пытался так сделать и даже моя простейшая модель http сервера когда-то заработала:
marsohod.org/index.php/projects/marsohod2/290-websrv
Но как мне узнать вообще такие идеи кому интересны или нет?
Я знаю, что мир сейчас наоборот двигается в сторону виртуализации и всяких SDN (Software Defined Network), но может и чисто аппаратные решения имеют свои плюсы?
По крайней мере сделать в ПЛИС/FPGA web сервер, который будет отдавать статику по HTTP — я не думаю что это сильно сложно.
Думаю, тот же высокочастотный трейдинг? Где под конкретные протоколы делаются свои FPGA железки.
К примеру, хотя не совсем то: www.es.ele.tue.nl/mamps/web_server/files/report.pdf
так ведь есть подобные решения на рынке — f5 networks ltm, citrix netscaler.
в том числе и для обеспечения low latency, что критично для трейдеров, но там сильно ограничены возможности анализа/модификации пэйлоада в угоду большей производительности.
НЛО прилетело и оставило эту надпись здесь.
А какие плюсы у аппаратного решения, кроме скорости?

Имхо, у аппаратного решения много минусов:
* подбор кадров (сколько в мире специалистов по nginx, и сколько специалистов по этому решению?)
* нет стандартной реализации (нужно будет сделать и протестировать 1U железку)
* массовая замена железа (вместо стандартного сервера нужно будет ставить эту железку)
* соответствие по функционалу (нужно, чтобы аппаратное решение поддерживало весь требуемый функционал)
* объем настройки (нужно переделать все конфиги)
* сложность при правке конфига (перепрошивать железку?)
* сложность обновления (достаточно будет перепрошить железку, или нужно новую железку?)

Поэтому (опять же, имхо) «скорость» станет существенным фактором, если прирост будет не на 15-30%, а в 5-10 раз или больше.
Т.е. оно должно финансово переплюнуть все затраты на переход.
А ведь железо дешевеет, т.е. стандартный подход все дешевеет и дешевеет, а следовательно «профит» от железки должен быть все больше и больше, чтобы оправдать себя.

Лично мне не кажется, что будет большой плюс в скорости.
Сами по себе *nix+nginx добавляют очень маленькие накладные расходы, т.е. очень эффективно используют аппаратные ресурсы.
Вот если задействовать ресурсы GPU…

Но и при этом nginx — это же не просто отдача статики.
Это ещё куча логики + куча доп. модулей.
Чего стоит обработка запросов с использованием map и регулярок.
Ещё всякие fastcgi, uwsgi и прочие *gi, без которых nginx теряет половину привлекательности.
А у многих ещё прикручены memcache/redis/lua/perl.
Если все это реализовывать в ПЛИС, то сколько будет стоить разработка?
НЛО прилетело и оставило эту надпись здесь.
Я в этом не специалист, но предположу, что там другой процессор.
А значит, его не следует сравнивать с x86/x64, как мы сравниваем i3 и i5.
Например, вспомним bitcoin.
Сравните Mhash/s у CPU и FPGA.
en.bitcoin.it/wiki/Non-specialized_hardware_comparison#CPUs.2FAPUs
en.bitcoin.it/wiki/Mining_hardware_comparison
НЛО прилетело и оставило эту надпись здесь.
вот в целом вы правильно пишите, но тоже надо понимать, что вендоры прилагают массу усилий, чтобы создать некую экосистему вокруг своих продуктов.

я по работе часто сталкиваюсь и nginx и с «аппаратными» контроллерами доставки приложений. это целый сегмент рынка.
они жутко программируемы, в них используются криптоакселераторы и всяческие аппаратные прибамбасы для ускорения и оптимизации.

и каждый вендор зомбирует своими преимуществами — организуют тренинги и обучение, проводят вебексы и презентации для заказчиков.
у таких компаний есть свои клиенты и куча заказов, потому что не везде есть годные специалисты, способные обеспечить доступность приложений на кластере nginx, а после ухода из компании не каждый новый специалист будет способен всю эту инфраструктуру поддерживать.

а с таким вот «аппаратным» контроллером вы просто посылаете человека на курсы, он читает подробную документацию, которой сопровождается оборудование и без особых проблем инфраструктура продолжает жить.

чаще всего решает цена
Согласен.
Но для России, насколько я знаю, цена на такие аппаратные решения очень кусается.
А с падением курса рубля она стала кусаться только сильнее.
Т.е. сейчас стоимость специалистов упала по сравнению со стоимостью оборудования (в том числе и такого).
Могу предположить, что в других странах ситуация противоположна — оборудование дешевеет, специалисты дорожают.
И там выбор в сторону аппаратных решений реальнее.
Она кусается не только для России. Многие клиенты с удовольствием отмечают, что NGINX Plus c поддержкой им обошелся буквально на порядок дешевле.
К своему ответу ещё хочу добавить, что сейчас сервер на nginx может отдавать, например 80 Гбит/с с себя.
А не с себя (т.е. просто проксировать) и того больше.
Поэтому нет вопроса «как бы это ускорить?», скорее стоит вопрос «чем все это нагрузить?».
Какой самый эффективный способ прицепить свои обработчики на C\C++ к nginx?
Если через написание модуля — то планируется ли какая-либо вменяемая документация \ API, кроме известной статьи 10-летней давности?
Если через fcgi — насколько данное решение будет уступать модулю по производительности?
НЛО прилетело и оставило эту надпись здесь.
*CGI/HTTP должно хватить для большинства задач. Едва ли вы упретесь в протокол, зато получится гибко, стабильно и это будет на порядок легче поддерживать.

Планы были, но пока отсутствует понятный, формализованный, стабильный и безопасный API для сторонних модулей, любая такая документация будет неполноценной и быстро устаревать. На данный момент самая вменяемая документация — исходный код.
Наверное, если делать API для модулей, то совсем без копирования в памяти, а иначе-то оно и по fcgi неплохо.
Какой из зоопарка решений (https://blog.inventic.eu/2013/11/fastcgi-c-library-for-all-platforms-windows-mac-and-linux/) порекомендуете? Нужно, чтоб была мульти-платформенная обработка асинхр. событий (не харкоднутый select) и желательно не Boost.ASIO. Есть такие?
Если вопрос ко мне, то не могу ничего порекомендовать, поскольку нет такого опыта, не пользовался. Вообще протокол в самом базовом виде достаточно простой и можно свое написать за день.

И мне кажется обработкой событий не fastcgi библиотека должна заниматься.
Для чего-то он там есть (встречал как раз Boost.ASIO и select)…
Хорошо, есть вопрос.
Допустим, я хочу сделать игровой сервер (несколько игроков в общем мире). Игра нединамичная и потому протокол TCP. Как лучше реализовать обмен, чтобы потоков было поменьше?
Так же, как это делает nginx, асинхронно обрабатывая сокеты в неблокирующемся режиме.
В моей архитектуре было два потока на игрока: один занимается отправкой, второй — приёмом. Почему два? А потому, что сообщение с игрока А, после того, как обработается, будет разослано всем. Но всё равно многовато. Может, от второго потока удастся избавиться асинхронным вводом-выводом? — всё равно разбираться и разбираться.

Потому я и написал это в статью про NGINX, что у него есть чему научиться.А вот с чего начать?
Каша!

1. Асинхронный в/в — он в винде при использовании CompletionIO (порта завершения ввода/вывода), и кажется там ещё какой механизм был, оба требуют заранее передавать буфера откуда/куда поступят данные и заполнять OVERLAPPED структуру.
Те вы говорим ОС: нужно принять/отправить данные вот из этого буфера, в вот тот сокет (для файлов там ещё и смещения в файле нужно указывать куда читать/писать), и забываем про это. Когда всё будет готово нам приходит уведомление.
Так работает IIS и всё новодное типа хайлоад в мс. С 2к винды начиная они всё на это переносят.

2. Неблокирующий в/в это в BSD/Linux и винде (вроде, давно уже не кодил/читал) когда ты выставляешь на сокет/файл O_NONBLOCK и после этого каждый раз когда делаешь read()/write()/send()/recv()/… то тебе может вернутся 0 (-1 см доки по апи) и код ошибки обозначающий что операция не завершена. При этом нужно быть готовым что когда ты пытаешься записать 10мб то у тебя запишется 64к, и тебе вернётся что записано 64к, и нужно будет вызывать запись ещё еи ещё но самому сдвигать оффсет в буфере и уменьшать размер.
Или когда ты вызываешь recv() а данных в сокете нет он не залипнет, а сразу вернёт 0 байт прочитанных и код ошибки выставит что операция в процессе.

Для неблокирующего режима в BSD есть kqueue а в линухе epoll. (Кто начинал с kqueue будет плеватся от epoll, ибо огрызок)
Привязываешь дескриптор сокета/файла к этой хрени и задашь какие уведомления тебе интересны: можно прочитать, можно записать, или всё сразу.
Потом поток отправляешь ждать событий (сон) на соотвествующей функции: kevent() или epoll_wait(), когда они отпустят поток то у тебя будет как минимум void* (для epoll) привязанный к соотвествующему дескриптору. И флаги отдельно для чтения и записи что это уже можно делать (данные пришли/место в буфере появилось/приконектились).
В случае kqueue() будет и void* для данных отдельно для чтения и отдельно для записи, и сам int с дескриптором, и размер сколько можно прочитать/записать и EOF если соединение закрыто/конец файла и код ошибки.

Есть ещё select() — он везде доступен, но у него куча ограничений и неприятных моментов.
В винде неблокирующий режим можно ещё получить с помощью оконных сообщений (сокеты привязывать к окну).

Тебе нужен всего один поток, все сокеты засовываешь в kqueue/epoll и тупо отрабатываешь события на них.
Рекомендую по одному потоку на один kqueue/epoll, если потоков хочется моного то лучше расширить модель просто запустив потоки и обменивась между ними сообщениями. В kqueue это можно делать с помощью «пользовательских» фильтров (оч просто).
В epoll нужно будет использовать pipe() и просто писать в нужные, а поток их получит как будто из файла/сокета.
Так сделано в msd_lite: www.netlab.linkpc.net/wiki/ru:software:msd:lite и ещё паре программ по соседству, типа ssdpd.
В nginx примерно также, только у них потоки вынесены в отдельные процессы, и не уверен что процессы могут посылать друг другу сообщения/данные.

Модель один kqueue/epoll и пачка потоков — имеет много подводных камней, нужно 100 раз подумать прежде чем воспользоватся ей.
Например очень трудно отправить сообщение конкретному потому, сложности с общими данными, необходимость блокировок.
Те использовать это можно, но нужно чётко понимать что это даёт и насколько сильно ограничивает.
МС рекомендует (по крайней мере рекомендоавала в начале 200х) эту модель совместно со своим портов завершения в/в, притом в книжке было всё красиво, но был нюанс: там оно было в псевдокоде с предложением реализовать getcpuusge() и HasThreadIO() (есть ли у потока не завершённые задания которые он ставил) самостоятельно. Первое было относительно легко, а второе это уровень ядра или довольно экзотический код с интерлокед которое не дешевое. Лет через 5 эта функция появилась официально в PlatformSDK для ХР с каким то сп, а до того её энтузиасты откопали в 2к (или ХР без сп). Те мс сделало и придержало для себя.
IOCP в связке с пулом потоков работает. Для игр вот как раз статейка про него.
а почему бы вам не попробовать связку nginx->node.js->websocket? возможно, вам подойдет это решение…
А вот с чего начать?

Начать можно вот с этого: www.gnu.org/software/libc/manual/html_node/Server-Example.html
Очень простая штука на самом деле.
Простая, портабельная и эффективная, как топор.
Я с ней ещё 15 лет назад баловался, когда писал сетевые программки.
Для двух игроков вам этого хватит за глаза.

Когда освоите её и захочется стильного, быстрого и современного, легко сможете переключиться на это:
banu.com/blog/2/how-to-use-epoll-a-complete-example-in-c
Это в случае, если у вас сервер linux only.
НЛО прилетело и оставило эту надпись здесь.
Буду тем парнем, который скажет про Erlang.
Ну Nitrogen не всем по зубам, как и Cowboy. Там думать надо много да по иному. Функциональщина. Одни log-файлы бывают чего стоят. Есть, правда, не такой мозгодробильный Yaws, только его тоже мало жалуют.
Бывает для души с CMS Zotonic вожусь. Ух и забористая штука временами.
статья полезная, но слишком много метафор и эмоций — для большинства, кроме совсем уж дилетантов, «оно не надо»
Странно, что вы считаете полезным свой комментарий.
Как раз недавно использовал NGINX для нанрузочного тестирования F5 LTM, где объект этой статьи выступал в роли backend. Без тонкой настройки сетевых параметров ядра, каждый легко обрабатывал 50000 запросов в секунду на статике. (уперся в способности сетевой карты)
Нащупать потолок у F5 не получилось только на чистом http трафике (на 500к запросов он даже не потел). С TLS и всякими IDP функциями все оказалось прозаичнее
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.