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 людей в секунду, то именно в коннектах и будет счастье.