Fast-CGI vs WebApplication , плюсы и минусы

Цитата D_KEY @ 10.03.18, 15:59

asio тоже юзает kqueue.

Вот - вспомнил статью. Там в конце бэйнчмарки. Как сам автор признается - чисто для осознания примерной разницы.

Добавлено 10.03.18, 16:05

Цитата D_KEY @ 10.03.18, 15:59

Вообще в лучших традициях российских форумов тебе не на вопрос отвечают, а объясняют, почему ты не прав

Я привыкший

Цитата D_KEY @ 10.03.18, 15:59

Вообще в лучших традициях российских форумов тебе не на вопрос отвечают, а объясняют, почему ты не прав

Так при его постановке требований: «хочу, чтобы было быстро», непонятно, зачем он вообще в сторону FastCGI посмотрел. Это ж накладные расходы и заведомо медленней, чем веб-приложение на плюсах. =)

Цитата JoeUser @ 10.03.18, 15:43

Да в гробу я видал этот "боинг" на ослиной тяге.

+++++
PHP в режиме FastCGI средствами патча PHP-FPM + Nginx
http://funix.ru/how-to/php-v-rezhime-fastc...-fpm-nginx.html

Цитата

Высокой производительности веб-сервера можно достичь используя в качестве front-end Nginx, а в качестве back-end PHP-FastCGI-сервер.
Преимущества Nginx и FastCGI:
— Nginx легок, прост в настройке, является прокси-сервером, очень быстрый.
— FastCGI это самый быстрый и наиболее безопасный способ обработки запросов внешними программами.
При такой схеме возможно обрабатывать большое количество запросов за небольшое время. Nginx может использоваться как самостоятельный HTTP-сервер или как reverse proxy перед Apache или любым другим тяжелым веб-сервером, чтобы снять часть нагрузки. Apache при этом выступает в качестве бэк-енда для генерации динамического контента..

Еще хорошая статья на https://habrahabr.ru/post/64938/
PS
Когда то лет 20 тому я читал курс лекций по FastCGI.
Блин, забыл все уже нафиг...
Вот нашел еще одну интересную ссылку как раз насчет C++
http://dml.compkaluga.ru/forum/index.php?showtopic=89845

Сообщение отредактировано: Oleg2004 - 10.03.18, 16:29

Цитата D_KEY @ 10.03.18, 15:59

Вообще в лучших традициях российских форумов тебе не на вопрос отвечают, а объясняют, почему ты не прав

Так тема в соотв. разделе ))

Цитата JoeUser @ 10.03.18, 16:04

Цитата D_KEY @ 10.03.18, 15:59

asio тоже юзает kqueue.

Вот - вспомнил статью. Там в конце бэйнчмарки. Как сам автор признается - чисто для осознания примерной разницы.

Какая-то поделка в качестве аргумента?

Добавлено 10.03.18, 18:04
Там вообще очень странные цифры для всех вариантов. Должно быть гораздо лучше

Цитата JoeUser @ 10.03.18, 16:04

Там в конце бэйнчмарки.

Ага…

Цитата D_KEY @ 10.03.18, 12:54

Не знаю, меня вот синтаксис rust очень отвращает.

А что с ним не так? По-моему разве что про лайфтаймы можно сказать что-то подобное, остальное же вполне обычные конструкции, ничем принципиально не отличающиеся от таковых в прочих языках. Код уж точно более читаемый получается, чем в случае хаскеля или какого-нибудь лиспа

Цитата OpenGL @ 10.03.18, 20:20

Код уж точно более читаемый получается, чем в случае хаскеля или какого-нибудь лиспа

Спорное утверждение.

Цитата korvin @ 10.03.18, 18:18

Ага…

Не, ну ты чё! Человека от java воротит, а ты ему Шипилёва! Да еще без красной шляпы!

Цитата OpenGL @ 10.03.18, 20:20

Цитата D_KEY @ 10.03.18, 12:54

Не знаю, меня вот синтаксис rust очень отвращает.

А что с ним не так?

Ну вкусовщина же
Тяжело читать код. Даже когда вроде бы все понимаешь.
Короткие ключевые слова и названия вместе с :: сочетаются плохо. Как мне кажется < > пишут чаще, чем обычно в плюсах. Лайфтаймы просто нечитаемая херня. ! для макросов не улучшает читаемость, мягко скажем, тем более, что он же используется для "расходящихся" функций. Всякие let mut, &mut, MyType::new и т.п. Паттерны в стиле obj.foo(...).bar(...).expect(...) unwrap() и т.д. Странные конструкции вроде loop, когда нужно искать break в теле. Какие-то запятые в структурах после членов. Всякая колбасня со строками, &'static, &* и to_string(). Ещё одни "скобочки" в виде || в лямбдах. Уродский синтаксис меток циклов. В сочетании с остальным очень плохо смотрится синтаксис ограничений на параметры дженериков(так же ещё они по + совмещаются, что ИМХО странно). Синтаксис <>:: одно из худших решений, что я видел в яп.

Я мог бы продолжить, но это не слишком интересно

К семантике претензий особых нет. Хорошая веха в истории языков программирования. Гораздо интереснее того же go.

Цитата D_KEY @ 10.03.18, 15:59

Вообще в лучших традициях российских форумов тебе не на вопрос отвечают, а объясняют, почему ты не прав

Дайте я отвечу по теме
За время срача, уже б давно б сделал обе реализации да потестил

Свой http, один фиг, имплементить не будешь (иначе, я тоже расскажу кто ты ), так-что с точки зрения реализации -- один фиг.
WebApp можно поставить на отдельную от балансировщика тачку. Впрочем, fcgi вместе с сервером можно точно также поставить за балансировщиком. Всё, разница закончилась

Цитата OpenGL @ 10.03.18, 20:20

Код уж точно более читаемый получается, чем в случае хаскеля или какого-нибудь лиспа

К haskell надо привыкнуть. Когда ты в контексте, читается все нормально
Там нет такой семантики, для которой бы требовались активный синтаксический сахар. Читать можно, если понимаешь семантику происходящего (а с этим как правило больше проблем там, чем с синтаксисом).
По поводу лиспа соглашусь - очень тяжело мне его читать.

Добавлено 10.03.18, 23:37

Цитата negram @ 10.03.18, 23:30

Свой http, один фиг, имплементить не будешь (иначе, я тоже расскажу кто ты )

Мне кажется, что автор темы вполне готов

Цитата

Свой http, один фиг, имплементить не будешь

Да? Щя тебе каааак скажут, что на перле - нет проблем...

Сообщение отредактировано: Астарот - 11.03.18, 00:01

За время всех клавиатурных баталий я сделал, лично для себя, выводы:

1) Нужно пилить приложение в форме WebApplication
2) Оценить необходимость изучения и использования ЯП Rust и Go
3) Если п.2 будет не оценен по достоинству - остановится на C/C++
4) Если будет реально уйти от С++ к Си - сделать это

Пока вот так.

Цитата JoeUser @ 11.03.18, 01:09

4) Если будет реально уйти от С++ к Си - сделать это

Ты знаешь, есть ещё WebAssembly... не останавливайся.