тут мысля посетила... что если вместо велосипеда из boost::asio взять готовый NGINX?
он же самый быстрый на планете, в данный момент, благодаря своему thread pool-у, и у него есть решение (модуль) под любой чих
что если то самое место, где порождаются потоки, обернуть в C++ и запускать свою ф-ю, которая будет возвращать HTML-контент
такое можно провернуть?
ну или, если не получится в C++, то в C то должно получиться?

PetroNotC SharpТогда у вас получится следующий стоящий за nginx - веб сервер апач. Он как раз формирует динамичные веб страницы.
я как раз таки НЕ предлагаю писать отдельного демона, это доп.расходы на передачу команд и данных между ними
а также это потери в потоках, которые нужно будет делить между NGINX и демоном
эффективнее прямо в код NGINX воткнуть свой
PetroNotC SharpPHP - апач
у PHP это PHP-fpm, который отдельный демон, и он никак не привязан к апачу. Также прекрасно работает с Nginx.

kolobok0Они сами могут быть кем угодно и в любой ипостасии...
сами не могут, нужен программист
...который напишет велосипед

MasterZivPetroNotC Sharpkolobok0,
Ему то динамика нужна. Самому теги html ваять на 80 порту.

Ну Wt, Qt...
https://www.webtoolkit.eu/wt/src/treeview-dragdrop
да это ппц дичь
а это "Hello, world" у них: https://www.webtoolkit.eu/wt/src/hello
чё-то ну его нафиг в это вникать, всё проще делается

kolobok0полудух,

возможно покажется ответ в сторону...
но посмотрите в сторону микросервисов+контейнеров. одна из фишек контейнеров - пофигу код реализации. возможно это то что Вам поможет..
да это всё отдельные демоны

PetroNotC Sharpв вебе главное Шаблонизация (строки), Генерация (теги HTML), Кэширование.
Ничего этого нет ни в дельфи, ни в асме, ни в плюсах.
это есть во фреймворках
и в плюсах есть веб-фреймворки (причём довольно жирные)
в дельфях тоже подозреваю, что есть
в асме конечно нету (и не надо)
но шаблонизация HTML довольно просто делается и без фреймворков - собрал функции по .h-файлам и дёргаешь какие надо
а кэш ещё проще.
В общем это всё не тема для данной темы
тут про эффективный веб-сервер

kolobok0на сях можно решать, но Вы поймёте всю опрометчивость решения(или проверите обоснованность такого решения), когда столкнётесь например с WebSocket, JSON, HTTPS и т.д.. Т.е. решать такие вещи в рукопашную - мягко говоря надо иметь веские причины.
да не собираюсь я свой HTTPS писать
оно всё есть в NGINX уже
вопрос стоит предельно просто, выбора всего 2: либо юзать NGINX + демон (ну не хочу я boost::beast)
либо в сам NGINX зашить код (просто потому, что речь о C++, а не ПХП, и существует такая возможность)
вот и всё.
А вас всё заносит куда-то в кювет (

PetroNotC Sharpполудухпросто, выбора всего 2:демон лучше.
Не надо курочить сабж на нижнем уровне. Разделяйте слои.
во! наконец-то первое полноценное сообщение по теме
и мы ведь даже не добрались ещё до второй страницы

вот на слове "лучше" хотелось бы потоптаться...
во1, как уже упоминал выше, мы теряем половину потоков (их заберёт NGINX)
во2, мы теряем на скорости из-за передачи текстовых блоков (большие текстовые массивы надо будет перекладывать в памяти)
оно конечно неизбежно, когда речь про ПХП/питон/you_name_it
но когда речь про C++, это же прекрасная возможность изъ*бнуться!
в конце-концов... сегодня же пятница!
почему "не надо курочить сабж", вдруг оно того стоит?

maytonполудухтут мысля посетила... что если вместо велосипеда из boost::asio взять готовый NGINX?
он же самый быстрый на планете, в данный момент, благодаря своему thread pool-у, и у него есть решение (модуль) под любой чих
что если то самое место, где порождаются потоки, обернуть в C++ и запускать свою ф-ю, которая будет возвращать HTML-контент
такое можно провернуть?
ну или, если не получится в C++, то в C то должно получиться?
Все таки NGINX это не application server. Я думаю что сильно сложную логику на нем вы не насетапите.
почему? У меня же под пальцем весь C++, чего я не могу насетапить, в БД не смогу сходить, или string собрать, или графы посчитать?

PetroNotC Sharpполудухэто же прекрасная возможность изъ*бнуться!))))
А почему ставят на статику впереди апач если взади томкат САМ веб сервер?
ну причина только одна - статика это готовый HTML/JPG, а динамику надо писать на языке программирования
и обычно этот язык НЕ C, на котором написан сам NGINX
поэтому чтобы работать с динамикой NGINX шлёт всё другому демону, который генерит ему ответку на каком-то своём языке (ПХП).
А у меня как раз ситуация, когда язык именно C/C++ и можно НЕ разделять NGINX и отдельный модуль для генерации динамики/логики.
И вот я хочу из этой ситуации выжать максимум.

PetroNotC SharpполудухИ вот я хочу из этой ситуации выжать максимум.уже было.
Когда вместо слоя доступа к данным MDAC вы курочили в кавычках бд делая туда инъекции наркотика С кода.

Я курочил БД делая туда инъекции С-кода?
не было такого.
Dimitry Sibiryakovполудухчто если вместо велосипеда из boost::asio взять готовый NGINX?
он же самый быстрый на планете, в данный момент, благодаря своему thread pool-у

Самый быстрый среди HTTP серверов. Это то же самое что "самый быстрый трёхколёсный велосипед".
ну или "самый быстрый шоссейный велосипед"
он обрабатывает миллионы подключений в секунду, ВОТ что главное.
kolobok0где то тут или ышо каком форуме пробегало - как народ максимально ускорил вэб сервак, какого то онлайн гиганта. тупо всё превратили в HTML и убрали всю динамику...

так что если Nginx и макс скорость - то там ни пых пыхом, ни сями и не пахнет , от слова совсем...
ну, кстати, нет... НЕ факт, что скинув всё в html-файлы оно станет быстрее, чем когда всё в памяти (пусть даже динамика)
т.е. если БД типа редиски, то это может сработать даже быстрее, чем по диску файлы искать...
muut.com вот как раз такой (правда сам фронтэнд не помню на чём... что-то вроде питона)

kealon(Ruslan)полудухтут мысля посетила... что если вместо велосипеда из boost::asio взять готовый NGINX?
он же самый быстрый на планете, в данный момент, благодаря своему thread pool-у, и у него есть решение (модуль) под любой чих
что если то самое место, где порождаются потоки, обернуть в C++ и запускать свою ф-ю, которая будет возвращать HTML-контент
такое можно провернуть?
ну или, если не получится в C++, то в C то должно получиться?опоздали, уже делают
моды php встраивают например
ну вот кстати да, есть такое мнение:
авторЕсли уж и писать на сях то сразу модуль в nginx

maytonА что такое вообще - быстрый?

Вот facebook быстрый? А за счет чего?

Наверное не потому-что быстро отдает контент. Может и медленно.
Просто скролл спроектирован так что пока поциент разглядывает котика.
Подгружается следующая картинка с котиком ниже. Разумеется систему
можно ушатать быстрым скроллом. Но кто так делает? Все читают с человеческой
скоростью.
ага, а DDoS ещё не изобрели... Лёг бы он давно, и не поднялся никогда.
у FB был свой компилятор PHP-кода, который его заранее переводил в бинарник
потом Go подъехал...
ну и кэши конечно решают... главным тормозом всегда остаётся I/O (БД/диск)
когда БД в редиске, сайт летает. А когда всё в кэше, то вообще мгновенно отдаёт.
Dimitry Sibiryakovполудухон обрабатывает миллионы подключений в секунду, ВОТ что главное.

Не в подключениях счастье. Неважно сколько их он может принять когда потом начинается
парсинг текстового протокола с полным квитированием.
да текстовый протокол это меньшая из бед
текстовый протокол вообще-то везде есть, хоть как вы там бэкенд построите, он всегда будет, потому что он основа HTTP-протокола.
Главной проблемой остаётся именно бэкенд. И если на нём всё быстро, то именно кол-во подключений и зарешает.
А когда там какой-нибудь PHP-fpm сначала должен скомпилить, а потом (даже если оно уже в кэше) с максимальной НЕэффективностью будет заниматься рассчётами (в PHP7 int занимает 40 (!!!) байт, а в ПХП5 вообще 76), и всё это ещё через БД без SSD и с миллиардом строк, вот тогда да - "не в подключениях счастье".

Dimitry SibiryakovPetroNotC Sharpsql.ru считается быстрым

Открываем для него в браузере "информацию о странице" и видим "размер: 13к".
Повторяем для любого другого форума и видим мегабайт. Как я и говорил, не в коннектах счастье.
если на sql.ru вломятся 30000 людей в секунду, то именно в коннектах и будет счастье.

PetroNotC Sharpполудух,
2009 год))
https://habr.com/ru/post/61532/
fastcgi это протухшее легаси-гомно, зачем оно надо?

PetroNotC Sharpполудухесли на sql.ru вломятся 30000 людей в секунду, то именно в коннектах и будет счастье.за nginx как бансировщиком ставится еще один веб сервер. Горизонтальное масштабирование.
А вы что будете делать?
эдак можно и на каждое подключение ставить отдельный веб-сервер и гордиться - "какой я масштабист"