Комментарии 32
Для меня это была интересная статья.
Хотя бы теперь понятна принципиальная разница между apache и nginx.
Но у меня другой вопрос. А что если сделать аппаратный http сервер? Можно например зашить логику http сервера в ПЛИС. Я пытался так сделать и даже моя простейшая модель http сервера когда-то заработала:
marsohod.org/index.php/projects/marsohod2/290-websrv
Но как мне узнать вообще такие идеи кому интересны или нет?
Я знаю, что мир сейчас наоборот двигается в сторону виртуализации и всяких SDN (Software Defined Network), но может и чисто аппаратные решения имеют свои плюсы?
По крайней мере сделать в ПЛИС/FPGA web сервер, который будет отдавать статику по HTTP — я не думаю что это сильно сложно.
Хотя бы теперь понятна принципиальная разница между 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
К примеру, хотя не совсем то: www.es.ele.tue.nl/mamps/web_server/files/report.pdf
так ведь есть подобные решения на рынке — f5 networks ltm, citrix netscaler.
в том числе и для обеспечения low latency, что критично для трейдеров, но там сильно ограничены возможности анализа/модификации пэйлоада в угоду большей производительности.
в том числе и для обеспечения low latency, что критично для трейдеров, но там сильно ограничены возможности анализа/модификации пэйлоада в угоду большей производительности.
НЛО прилетело и опубликовало эту надпись здесь
А какие плюсы у аппаратного решения, кроме скорости?
Имхо, у аппаратного решения много минусов:
* подбор кадров (сколько в мире специалистов по nginx, и сколько специалистов по этому решению?)
* нет стандартной реализации (нужно будет сделать и протестировать 1U железку)
* массовая замена железа (вместо стандартного сервера нужно будет ставить эту железку)
* соответствие по функционалу (нужно, чтобы аппаратное решение поддерживало весь требуемый функционал)
* объем настройки (нужно переделать все конфиги)
* сложность при правке конфига (перепрошивать железку?)
* сложность обновления (достаточно будет перепрошить железку, или нужно новую железку?)
Поэтому (опять же, имхо) «скорость» станет существенным фактором, если прирост будет не на 15-30%, а в 5-10 раз или больше.
Т.е. оно должно финансово переплюнуть все затраты на переход.
А ведь железо дешевеет, т.е. стандартный подход все дешевеет и дешевеет, а следовательно «профит» от железки должен быть все больше и больше, чтобы оправдать себя.
Лично мне не кажется, что будет большой плюс в скорости.
Сами по себе *nix+nginx добавляют очень маленькие накладные расходы, т.е. очень эффективно используют аппаратные ресурсы.
Вот если задействовать ресурсы GPU…
Но и при этом nginx — это же не просто отдача статики.
Это ещё куча логики + куча доп. модулей.
Чего стоит обработка запросов с использованием map и регулярок.
Ещё всякие fastcgi, uwsgi и прочие *gi, без которых nginx теряет половину привлекательности.
А у многих ещё прикручены memcache/redis/lua/perl.
Если все это реализовывать в ПЛИС, то сколько будет стоить разработка?
Имхо, у аппаратного решения много минусов:
* подбор кадров (сколько в мире специалистов по 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
А значит, его не следует сравнивать с 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 и с «аппаратными» контроллерами доставки приложений. это целый сегмент рынка.
они жутко программируемы, в них используются криптоакселераторы и всяческие аппаратные прибамбасы для ускорения и оптимизации.
и каждый вендор зомбирует своими преимуществами — организуют тренинги и обучение, проводят вебексы и презентации для заказчиков.
у таких компаний есть свои клиенты и куча заказов, потому что не везде есть годные специалисты, способные обеспечить доступность приложений на кластере nginx, а после ухода из компании не каждый новый специалист будет способен всю эту инфраструктуру поддерживать.
а с таким вот «аппаратным» контроллером вы просто посылаете человека на курсы, он читает подробную документацию, которой сопровождается оборудование и без особых проблем инфраструктура продолжает жить.
чаще всего решает цена
Согласен.
Но для России, насколько я знаю, цена на такие аппаратные решения очень кусается.
А с падением курса рубля она стала кусаться только сильнее.
Т.е. сейчас стоимость специалистов упала по сравнению со стоимостью оборудования (в том числе и такого).
Могу предположить, что в других странах ситуация противоположна — оборудование дешевеет, специалисты дорожают.
И там выбор в сторону аппаратных решений реальнее.
Но для России, насколько я знаю, цена на такие аппаратные решения очень кусается.
А с падением курса рубля она стала кусаться только сильнее.
Т.е. сейчас стоимость специалистов упала по сравнению со стоимостью оборудования (в том числе и такого).
Могу предположить, что в других странах ситуация противоположна — оборудование дешевеет, специалисты дорожают.
И там выбор в сторону аппаратных решений реальнее.
К своему ответу ещё хочу добавить, что сейчас сервер на nginx может отдавать, например 80 Гбит/с с себя.
А не с себя (т.е. просто проксировать) и того больше.
Поэтому нет вопроса «как бы это ускорить?», скорее стоит вопрос «чем все это нагрузить?».
А не с себя (т.е. просто проксировать) и того больше.
Поэтому нет вопроса «как бы это ускорить?», скорее стоит вопрос «чем все это нагрузить?».
Какой самый эффективный способ прицепить свои обработчики на C\C++ к nginx?
Если через написание модуля — то планируется ли какая-либо вменяемая документация \ API, кроме известной статьи 10-летней давности?
Если через fcgi — насколько данное решение будет уступать модулю по производительности?
Если через написание модуля — то планируется ли какая-либо вменяемая документация \ API, кроме известной статьи 10-летней давности?
Если через fcgi — насколько данное решение будет уступать модулю по производительности?
НЛО прилетело и опубликовало эту надпись здесь
*CGI/HTTP должно хватить для большинства задач. Едва ли вы упретесь в протокол, зато получится гибко, стабильно и это будет на порядок легче поддерживать.
Планы были, но пока отсутствует понятный, формализованный, стабильный и безопасный API для сторонних модулей, любая такая документация будет неполноценной и быстро устаревать. На данный момент самая вменяемая документация — исходный код.
Планы были, но пока отсутствует понятный, формализованный, стабильный и безопасный API для сторонних модулей, любая такая документация будет неполноценной и быстро устаревать. На данный момент самая вменяемая документация — исходный код.
Наверное, если делать API для модулей, то совсем без копирования в памяти, а иначе-то оно и по fcgi неплохо.
Какой из зоопарка решений (https://blog.inventic.eu/2013/11/fastcgi-c-library-for-all-platforms-windows-mac-and-linux/) порекомендуете? Нужно, чтоб была мульти-платформенная обработка асинхр. событий (не харкоднутый select) и желательно не Boost.ASIO. Есть такие?
Хорошо, есть вопрос.
Допустим, я хочу сделать игровой сервер (несколько игроков в общем мире). Игра нединамичная и потому протокол TCP. Как лучше реализовать обмен, чтобы потоков было поменьше?
Допустим, я хочу сделать игровой сервер (несколько игроков в общем мире). Игра нединамичная и потому протокол TCP. Как лучше реализовать обмен, чтобы потоков было поменьше?
Так же, как это делает nginx, асинхронно обрабатывая сокеты в неблокирующемся режиме.
В моей архитектуре было два потока на игрока: один занимается отправкой, второй — приёмом. Почему два? А потому, что сообщение с игрока А, после того, как обработается, будет разослано всем. Но всё равно многовато. Может, от второго потока удастся избавиться асинхронным вводом-выводом? — всё равно разбираться и разбираться.
Потому я и написал это в статью про 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.
статья полезная, но слишком много метафор и эмоций — для большинства, кроме совсем уж дилетантов, «оно не надо»
Как раз недавно использовал NGINX для нанрузочного тестирования F5 LTM, где объект этой статьи выступал в роли backend. Без тонкой настройки сетевых параметров ядра, каждый легко обрабатывал 50000 запросов в секунду на статике. (уперся в способности сетевой карты)
Нащупать потолок у F5 не получилось только на чистом http трафике (на 500к запросов он даже не потел). С TLS и всякими IDP функциями все оказалось прозаичнее
Нащупать потолок у F5 не получилось только на чистом http трафике (на 500к запросов он даже не потел). С TLS и всякими IDP функциями все оказалось прозаичнее
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
NGINX изнутри: рожден для производительности и масштабирования