Для меня это была интересная статья.
Хотя бы теперь понятна принципиальная разница между 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, что у него есть чему научиться.А вот с чего начать?
НЛО прилетело и оставило эту надпись здесь.
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 функциями все оказалось прозаичнее
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.