Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 114
Вполне может подойти для случаев, когда критично быстродействие.
ab показывает среднее время выполнения одного запроса при 10 конкурентных около 2,5-3ms. Кажется это не так уж и быстро. Наверное от того что ведется синхронная работа с сокетом.
Статья про оптимизацию. Настоятельно советую почитать, чтобы больше не говорить такого.
rsdn.ru/article/philosophy/Optimization.xml
Краткое содержание статьи: «Оптимизировать надо узкие места»
rsdn.ru/article/philosophy/Optimization.xml
Краткое содержание статьи: «Оптимизировать надо узкие места»
Вполне может подойти, когда работать с альтернативой нет возможности.
После «Hello, world» я попробую написать web-интерфейс к своей программе. Писать не так уж и сложно, просто сказывается сильная неразвитость веб-направления на с++ и отсутствие хороших библиотек.
Fastcgi-программы на c/c++ очень похожи по структуре на fastcgi-программы на perl. Можно писать с оглядкой на множество существующих perl-скриптов.
Fastcgi-программы на c/c++ очень похожи по структуре на fastcgi-программы на perl. Можно писать с оглядкой на множество существующих perl-скриптов.
После «Hello, world» я попробую написать web-интерфейс к своей программе. Писать не так уж и сложно, просто сказывается сильная неразвитость веб-направления на с++ и отсутствие хороших библиотек.
Fastcgi-программы на c/c++ очень похожи по структуре на fastcgi-программы на perl. Можно писать с оглядкой на множество существующих perl-скриптов.
Fastcgi-программы на c/c++ очень похожи по структуре на fastcgi-программы на perl. Можно писать с оглядкой на множество существующих perl-скриптов.
Насколько мне известно abn.com.ua баннерная сеть с оборотом 11М написана как раз на си… Таким способом или другим, но факт.
у меня один знакомый сейчас пишет интернет магазин на С++.
Если уж и писать на сях то сразу модуль в nginx
А если пишете десктоп-приложение, то сразу как расширение ядра ос?
Я тоже, когда «пробовал» писать что-то для веб на С/С++ писал модуль для apache. Хотя я не вспомню сейчас как там что, но у меня такое ощущение, что для хелло ворлд у меня гораздо меньше строк получилось )
Меньше кода — меньше ошибок © )
Меньше кода — меньше ошибок © )
Есть ли какие-нибудь фреймворки на C/C++?
Полноценных я не нашел. можно внимательно присмотреться к www.nongnu.org/fastcgipp/.
cryp.to/publications/fastcgi/#FRAMEWORK — здесь были намеки, но опять же реализации в сети я не нашел.
кстати, когда я написал точно такой же комментарий в другом топике, то надо мной долго смеялись. Теперь я не один. =)
cryp.to/publications/fastcgi/#FRAMEWORK — здесь были намеки, но опять же реализации в сети я не нашел.
кстати, когда я написал точно такой же комментарий в другом топике, то надо мной долго смеялись. Теперь я не один. =)
Klone, мини-фреймворк для С. Изначально предполагался для веб-интерфейсов к какому-либо железу/прочему лоулевелу. Довольно забавная штучка.
а если без сокетов?
Есть вот такая табличка по соотношению способов коммуникации и типов запуска программы:
STDIN Domain Socket TCP/IP Socket Remote app PM starts app
External N Y Y Y N
Dynamic Y N N N Y
Static N Y Y N Y
без сокетов можно использовать только динамическим способом запуска, при этом поток stdin указывается при порождении процесса программы.
Если вы спрашивали о скорости работы, то я не знаю, должно быть быстрее.
STDIN Domain Socket TCP/IP Socket Remote app PM starts app
External N Y Y Y N
Dynamic Y N N N Y
Static N Y Y N Y
без сокетов можно использовать только динамическим способом запуска, при этом поток stdin указывается при порождении процесса программы.
Если вы спрашивали о скорости работы, то я не знаю, должно быть быстрее.
Ээто безусловно интересно но… Вряд ли когда-нибудь буду на С/С++ писать сайты, слишком уж это. Вот на ассемблере — это да, сила! Зачем нам полумеры :E
Хотя на счет того, что не буду на сях писать сайты, это я погорячился. Более правильно сказать — fastcgi вряд ли буду юзать, а вот под.нет возможно и придется в определенных местах использовать C++.
Где-то я видел графики сравнения по скорости между php, perl, ruby, cgi, еще чего-то. Если кто-нибудь поделиться — буду благодарен. Интересно.
Где-то я видел графики сравнения по скорости между php, perl, ruby, cgi, еще чего-то. Если кто-нибудь поделиться — буду благодарен. Интересно.
Интересно в карму насрали любители С++ или не-любители ассемблера? :) Хотя вроде ни то ни другое не опускал и не пропагандировал
называется мы не ищем легких путей, обычные сайты: блоги, магазины, корпоративные — php за глаза, а еще есть asp.net, java.
Можете ли привести пример сайта написанного на С++, хотя бы частично ?? Просто интересно посмотреть.
ebay.com — ключевые сервисы написаны на С++
Мне когда-то говорили, что мэйлру относится к таковым. Частично на С/С++, частично на перле.
Yahoo! Placemaker. Это сервис, вообще говоря. Back-end написан на C++ целиком и полностью.
paypal.com вроде на с++
Например, баннерные сети, счетчики. Только основная часть, т.е. выдача рекламного блока/картинки, но не сайт. Работает быстро.
ЭМ… А На чем написан Google? О_О
Несложная, непопулярная, но потихоньку развивающаяся браузерная игра — tuagir.ru, написана на С под фреймворк Klone.
Какие-то критически важные части LinkedIn, афаик, на Ц.
mp3.ru
Имхо, в большинстве случаев это совершенно не нужно. Гораздо проще и удобнее использовать точку входа на каком-нибудь пхп, а сишный или плюсовый код оформить подключаемым к php расширением. В память оно будет загружаться одновременно с апачем, обработка ввода и показом результатов будет заниматься php. А C/C++ будет заниматься ровно тем, чем должен: обрабатывать переданный набор данных и возвращать результат. Заодно это, как правило, даёт универсальность — одну библиотеку можно будет при необходимости использовать и из плюсовой программы, и из php, и еще откуда.
Если ради скорости на C++, то лучше вообще без apache.
Правда, тогда кроме C++ на занятый порт ничего не прикрутишь (резко сложность возрастает).
Правда, тогда кроме C++ на занятый порт ничего не прикрутишь (резко сложность возрастает).
Большое спасибо за статью. :)
Прочтя статью, до меня вдруг окончательно дошло, что такое FastCGI. И если вы тут предлагаете попробовать C++, то у меня возникло желание попробовать FastCGI + Java.
В какой-то момент деплой в сервлет контейнер, какие-то его падения и прочее стали просто задалбывать и занимать ощутимое время разработки. Окончательно разозлившись, я свалил на Ruby On Rails, чему очень рад.
В голове уже идея простого фреймворка аля RoR для Java. FastCGI + DB4O + еще что нибудь ;)
Но после прочтения статьи появилось желание попробовать, за что респект.
Прочтя статью, до меня вдруг окончательно дошло, что такое FastCGI. И если вы тут предлагаете попробовать C++, то у меня возникло желание попробовать FastCGI + Java.
В какой-то момент деплой в сервлет контейнер, какие-то его падения и прочее стали просто задалбывать и занимать ощутимое время разработки. Окончательно разозлившись, я свалил на Ruby On Rails, чему очень рад.
В голове уже идея простого фреймворка аля RoR для Java. FastCGI + DB4O + еще что нибудь ;)
Но после прочтения статьи появилось желание попробовать, за что респект.
Видел веб морду к базе данных написанную на C… При переезде на другой сервер отказалась работать… хорошо еще что программист был доступен, скинул исходники, и только после перекомпиляции заработало. Кстати и собиралось тольк gcc 2.96, другие уже с ошибками валились… Ужос в общем. Не и интерпретаторы не для интернета.
Очень интересная, по крайней мере для меня, тема.
Был бы признателен за продолжение темы.
Был бы признателен за продолжение темы.
Спасибо за статью. На практике, из моего опыта, могу сказать, что чаще всего C++ не используется непосредственно как CGI front-end. В одной из крупных интернет-компаний ;) применяется обычно следующее решение: в качестве фронт-энда выступает PHP код, который выполняет задачи связанные с авторизацией пользователей, начальным sanity check входных данных и т.п. Следующим компонентом идет прокси-модуль, который как правило, представляет собой расширение для PHP, которое уже непосредственно перенаправляет запросы к .so, в котором заключен высокопроизводительный С++ код. Это немного более громоздкое решение, но в долгосрочной перспективе оно работает лучше, т.к. все компоненты на своих местах и для каждой задачи мы используем наилучшим образом подходяющую технологию.
В частности, на подобной архитектуре построен Yahoo! Placemaker — наверное, я все же описал с массой ошибок, но в целом архитектура именно такая.
В частности, на подобной архитектуре построен Yahoo! Placemaker — наверное, я все же описал с массой ошибок, но в целом архитектура именно такая.
Поискал тесты производительности, да C++ все таки рулит:
elliottback.com/wp/ruby-vs-php-performance-revisited/
izumi.plan99.net/blog/index.php/2008/01/17/ruby-vs-php-performance/
elliottback.com/wp/ruby-vs-php-performance-revisited/
izumi.plan99.net/blog/index.php/2008/01/17/ruby-vs-php-performance/
Ну вот, глюк случился, продолжение сообщения:
www.wrensoft.com/zoom/benchmarks.html
Приведенные материалы конечно не являются истиной в последней инстанции, но более-менее картину можно представить. Да, С++ (CGI) рулит, но ему хорошую конкуренцию составляет .NET, и даже Руби приближается к нему по производительности, причем ближе многих (v1.9). Так что все таки стоит задуматься, а стоит ли использовать С++ для такой области как веб, учитывая что он не очень к этому приспособлен. Это не критика С++ никоим образом :)
www.wrensoft.com/zoom/benchmarks.html
Приведенные материалы конечно не являются истиной в последней инстанции, но более-менее картину можно представить. Да, С++ (CGI) рулит, но ему хорошую конкуренцию составляет .NET, и даже Руби приближается к нему по производительности, причем ближе многих (v1.9). Так что все таки стоит задуматься, а стоит ли использовать С++ для такой области как веб, учитывая что он не очень к этому приспособлен. Это не критика С++ никоим образом :)
Да стоит задуматься. Но очень рад, что есть такая возможность для его использования. Это дает всю мощь Си ++ =) (бесспорно я думаю), без которой порой пока очень сложно обойтись.
И еще. По бенчмаркам ASP.NET отстает от CGI на примерно 30%. Согласитесь это не мало.
Да, но по сравнению с другими участниками теста —.нет молодец :)
И еще — С++ вроде оптимизировать особо некуда больше. А в .NET постоянно выходят новые версии этого фреймворка, что я думаю положительно сказывается на производительности, может он когда-нибудь приблизится к С++.
Хотя скорее компьютеры просто станут еще на порядок мощнее и веб-разработчики забудут о разнице в производительности разных языков и технологий и будут писать на чем им удобнее :)
И еще — С++ вроде оптимизировать особо некуда больше. А в .NET постоянно выходят новые версии этого фреймворка, что я думаю положительно сказывается на производительности, может он когда-нибудь приблизится к С++.
Хотя скорее компьютеры просто станут еще на порядок мощнее и веб-разработчики забудут о разнице в производительности разных языков и технологий и будут писать на чем им удобнее :)
Ну вебформс — это не все, на чем пишут странички в асп.нет :)
Попробуйте те же асинхронные хендлеры. Нет надобности создания экземляров класса Page, прикручивания событий. Плюс Thread Pool. Да, а еще можно создать один экземпляр хендлера, в некотрых случаях это тоже может сказаться на производительности в лучшую сторону.
Попробуйте те же асинхронные хендлеры. Нет надобности создания экземляров класса Page, прикручивания событий. Плюс Thread Pool. Да, а еще можно создать один экземпляр хендлера, в некотрых случаях это тоже может сказаться на производительности в лучшую сторону.
Странно. а я слышал наоборот, Руби очень медленный. Например приложение на RoR приходится запускать заранее, так как иначе ответ на запрос был бы слишком медленным (а вот php работает быстрее!)
На сколько я знаю, и в тестах заметно — руби достаточно быстрый (особенно >v.1.9), а вот Ruby on Rails не самый быстрый из фреймворков, поэтому неторопливость RoRа переводят на язык, но под руби есть и другие фреймворки. То есть нельзя говорить про приложения на RoR и PHP — пхп это язык, а RoR — фреймворк. Можно сравнивать руби и пхп, что в тестах и делают.
источникик конечно очуметь, тока вот первая ссылка — вобоще 2008-ой год )
ну уж если С/C++, то тогда mod_helloworld… Благо апач с его apr — очень грамотное апи, не хуже чем и сам fastcgi протокол (всмысле, не сложнее). А выигрыш в скорости в таком случае совсем фатальный)
да и, не могу не заметить: современные маленькие дилетанты только думают, что «ну уж если веб то только интепретируемое...». Люди с мозгами знают что для некоторых задач си и 2 сервера лучше чем питон/пхп/чтоугодно и 20ть. Просто для бОльшего круга задач в этом смысла нет.
Веб-приложения на С`ях, тоже самое, что GUI приложения на php — можно, а нужно ли...?! Быстродействие — так настроем сервер, отключим все что не нужно — будет вам реактивная ракета…
А Вам, уважаемый автор, спасибо за статью :)))
А Вам, уважаемый автор, спасибо за статью :)))
Может не «настроем сервер» а купим новый?
Я вот несложные GUI-приложения пишу на javascript в .hta :-[
Зачастую это бывает намного продуктивнее и быстрее, чем открывать студию и ваять что-то там — кода получается меньше и делаю я это быстрее :) А на счет С и пхп — всетаки С более универсальный, и если гуи на пхп — зло, то вот в веб С живет потихоньку.
Зачастую это бывает намного продуктивнее и быстрее, чем открывать студию и ваять что-то там — кода получается меньше и делаю я это быстрее :) А на счет С и пхп — всетаки С более универсальный, и если гуи на пхп — зло, то вот в веб С живет потихоньку.
Если уж в коде используются сокеты, то не легче/оптимальнее ли будет писать сразу без апача, используя самописный веб сервер? Ведь его написать это совсем несложная задача.
А можно и не самописный, а например такой
Если мы будем писать отдельный web-сервер, то нам надо будет еще заморочиться:
1) с отдачей статических файлов
2) с безопасностью
3) с различными фичами, вроде access по ip, паролированием, рерайтами.
Оно нужно? :) С этим прекрасно справляется nginx.
1) с отдачей статических файлов
2) с безопасностью
3) с различными фичами, вроде access по ip, паролированием, рерайтами.
Оно нужно? :) С этим прекрасно справляется nginx.
Проблема в том что на си очень сложно 1) управлять памятью (надо делать умные указатели, так как обычные сборщики мусора плохи. а хороший вам никто не даст просто так, хотя именно на сервере тормоза из за сборки мусора не особо критичны) 2) Вырвиглазный синтаксис: надо писать заголовочные файлы в доп-е к обычным, кучу инклюдов и определять функции до (!!!!!!!) их использования. 3) тяжело писать ажурные конструкции из обхектов, ассоциаьтивных массивово и порчего, как в php. Вам придется самому реализовать такие объекты как хеши.работу со строками, подсчет ссылок… и все только ради того чтобы понять что вы сделали аналог php?
Хотя идея повысить производительность мне нравится. Интепретатор php тормоз, может инклудить файл дольше 1 мс и вообще мог бы работать и побыстрее!!! Жутко злит в общем.
Хотя идея повысить производительность мне нравится. Интепретатор php тормоз, может инклудить файл дольше 1 мс и вообще мог бы работать и побыстрее!!! Жутко злит в общем.
Насчет структур данных кагбэ stl. Да и boost тоже есть. C++ же не первый день существует, очень многое уже давно написано.
И вы считаете, что в Си такой же простой и приятный синтаксис для объектов/массивов как в php? И проблема управления памятью по прежнему остается))
А вот на языке типа D (конечно в нем пара мест тоже неидеальны например работа со строками) — было бы интересно попробовать писать придложения :)
А вот на языке типа D (конечно в нем пара мест тоже неидеальны например работа со строками) — было бы интересно попробовать писать придложения :)
Ну понятно же, что все зависит от поставленных целей и требуемого соотношения производительность/сложность разработки.
Более низкоуровневая работа с памятью — цена за быстродействие и отличительная особенность языка, а не проблема.
Нет, эта проблема (работа с памятью) должна решаться, частично компилятором (так как в части случаев он видит, где память можно уже освободить), частично каким-то средством вроде считалки ссылок, или сборщика мусора.
Так как писать вручную все эти выделения паямти и освобождения надоест быстро.
Так как писать вручную все эти выделения паямти и освобождения надоест быстро.
Поверьте, никто кроме автора не разбирается в том как должна работать его программа. если память где-то уже можно освободить, то автор должен это сделать. каким образом это произойдет неважно, будет это явное освобождение памяти или из стека будет вытолкнута переменная неважно. именно автор должен все учитывать и контролировать, а среда и компилятор ему подсказывать и помогать.
как говорил вирт, для написания программ дебагеры не нужны, если она написана правильно.
как говорил вирт, для написания программ дебагеры не нужны, если она написана правильно.
Это на словах так, автор все знает, а на деле над проектом работает куча людей, следствие баги с памятью, возьмите список уязвимостей в Windows например.
Это просто, когда у тебя в программе 3 функции (и то, мне бы стало лень руками писать delete, я бы навернг придумал что-нибудь, чтобы не писать), а когда огромное количесттво объектов, получаектся ерунда, программист не пишет код а только отслеживает баги.
Единственный способ борьбы с багами памяти — автоматическое управление памятью.
Это просто, когда у тебя в программе 3 функции (и то, мне бы стало лень руками писать delete, я бы навернг придумал что-нибудь, чтобы не писать), а когда огромное количесттво объектов, получаектся ерунда, программист не пишет код а только отслеживает баги.
Единственный способ борьбы с багами памяти — автоматическое управление памятью.
Чтобы не писать delete, средство уже придумано.
Вы правы виндовс довольно сложный программный продукт у которого были обнаружены множество ошибок при работе с памятью. именно поэтому в майкрософте постоянно усовершенствуют процесс разработки и требования к коду.
Я даже не против опционального средства для работы с памятью. и оно поверьте есть, ведь никто не запрещал сборщики мусора внутри программы.
все моменты неправильной работы с памятью должны быть выявленны на этапе компиляции программы, но не вовремя её работы.
Вы правы виндовс довольно сложный программный продукт у которого были обнаружены множество ошибок при работе с памятью. именно поэтому в майкрософте постоянно усовершенствуют процесс разработки и требования к коду.
Я даже не против опционального средства для работы с памятью. и оно поверьте есть, ведь никто не запрещал сборщики мусора внутри программы.
все моменты неправильной работы с памятью должны быть выявленны на этапе компиляции программы, но не вовремя её работы.
> именно поэтому в майкрософте постоянно усовершенствуют процесс разработки и требования к коду.
А надо — менять особености языка, или применять автоматическое управление памятью. Например, у меня на php ни разу программа не вылетала из-за багов с памятью.
Средства есть, не только сборщики мусора, но и умные указатели например.
> все моменты неправильной работы с памятью должны быть выявленны на этапе компиляции программы, но не вовремя её работы.
Это невозможно, так как неизветсно, сколько раз выполнится какой то цикл, по какой ветке пойдет выполенние, сколько раз будет вызвана функция.
А надо — менять особености языка, или применять автоматическое управление памятью. Например, у меня на php ни разу программа не вылетала из-за багов с памятью.
Средства есть, не только сборщики мусора, но и умные указатели например.
> все моменты неправильной работы с памятью должны быть выявленны на этапе компиляции программы, но не вовремя её работы.
Это невозможно, так как неизветсно, сколько раз выполнится какой то цикл, по какой ветке пойдет выполенние, сколько раз будет вызвана функция.
> Единственный способ борьбы с багами памяти — автоматическое управление памятью.
И как это помогает при зацикливании структур данных?
И как это помогает при зацикливании структур данных?
Сборщики мусора удяляют зацикленные структуры. счеткики ссылок — нет, но там можно применять хитрости, вроде слабых ссылок, или еще чего-нибудь.
Я в курсе, я имел в виду не совсем это (неверно выразился). Я про то, когда дизайн программы такой, что на какую-то мутную структуру остаётся всегда одна ссылка — например, из замыкания незаконченной процедуры или, более часто, из неаккуратно очищенного глобального или рано-инициализируемого контейнера.
Иными словами, автоматическое управление памятью не спасает от утечек памяти, вызванных кривым дизайном программы.
Иными словами, автоматическое управление памятью не спасает от утечек памяти, вызванных кривым дизайном программы.
Понтяно, что с кривыми руками трубно бороться — но можно, например, ограничивая выбор возможных конструкций програмистом. Я где-то выше писал, хорошо бы компилятором отслеживать такие ситуации, то есть в функции типа:
{
a = new Object();
dosmthWith(a);
// здесь компилятор может смело ставить delete a;
… много кода, не использующего a
return true;
}
Уничтожать локальную переменную a можно раньше выхода из функции.
{
a = new Object();
dosmthWith(a);
// здесь компилятор может смело ставить delete a;
… много кода, не использующего a
return true;
}
Уничтожать локальную переменную a можно раньше выхода из функции.
Всё равно лучше программиста никто это не отследит. Разве что ввести в сигнатуру dosmthWith свойство переменной a, которая подскажет, что эта a нигде не будет использоваться, типа:
dosmthWith( unlinkable<Object *> a ) {… }
Иначе если разрешить предложенную вами оптимизацию, нельзя будет реализовать интерфейсы-конструкторы вложенных структур (типа innerHTML).
В общем, много моментов. Гораздо проще, если речь идёт о C++ договориться всегда удалять объекты по указателям, определённым в текущем блоке, в этом же блоке, а в классе — в деструкторе этого класса. А для создания структур пользоваться обёртками в виде адаптирующих функций или классов.
dosmthWith( unlinkable<Object *> a ) {… }
Иначе если разрешить предложенную вами оптимизацию, нельзя будет реализовать интерфейсы-конструкторы вложенных структур (типа innerHTML).
В общем, много моментов. Гораздо проще, если речь идёт о C++ договориться всегда удалять объекты по указателям, определённым в текущем блоке, в этом же блоке, а в классе — в деструкторе этого класса. А для создания структур пользоваться обёртками в виде адаптирующих функций или классов.
P.S. Пример в бесшаблонном стиле:
dosmthWith( Object * unlinkable a ) {… }
dosmthWith( Object * unlinkable a ) {… }
Нет, вы не поняли. Я предлагаю уничтожать не объект, на который указывает «a», а только саму переменную, которая удерживает ссылку на него и не дает сборщику мусора удалить объект. Если где-то в функции doSmthWith() кто-то создает новую ссылку на объект, он не будет удален.
Естественно, речь идет о системах с подсчетом сылок или сборщиками мусора.
Естественно, речь идет о системах с подсчетом сылок или сборщиками мусора.
А, я думал, что вы написали на С++, где приведённая вами конструкция удаляет объект (ссылку-переменную со стека компилятор и так удаляет).
Собственно, современные GC-системы так и осуществляют контроль ссылок: пробегают по уничтожаемому стеку, если в объектах по ссылкам счётчик ссылок нулевой, то уничтожают и объекты. В Перле, например, по-другому, ссылки проверяются и объекты сносятся сразу после завершения предложения.
Но, как я раньше писал, это не спасает от мемликов за счёт подлинковывания из общих структур… :(
Собственно, современные GC-системы так и осуществляют контроль ссылок: пробегают по уничтожаемому стеку, если в объектах по ссылкам счётчик ссылок нулевой, то уничтожают и объекты. В Перле, например, по-другому, ссылки проверяются и объекты сносятся сразу после завершения предложения.
Но, как я раньше писал, это не спасает от мемликов за счёт подлинковывания из общих структур… :(
А это не так уж и сложно
А это не так уж и сложно
Спасибо автору за статью, т.к. очень не люблю фреймворки и все же очень надеюсь на то, что кто-то еще что-то пишет сам. Насчет того, нужно ли подобное, скажу да, т.к. сам лично сталкивался с ситуациями необходимого взаимодействия через веб-интерфейс с драйвером устройства на низком уровне, вот там-то как раз очень-очень и пригодилось сишное приложение.
пару слов про nginx. он поддерживает технологию fastcgi, но здесь придется использовать либо встроенный в php сервер fastcgi либо ставить стороний обработчик запросов, например lighttpd. я лично так и сделал, потому что первый жрет достаточное количество памяти, а из последнего выдрал утилиту spawn-fcgi, которая и занимается обработкой запросов.
А как с обработкой параметров?
А как с рестартом fcgi через 1000 запросов?
Чувство у меня такое что fcgi не умеет рестартить чилдов ну никак :(
Чувство у меня такое что fcgi не умеет рестартить чилдов ну никак :(
Почемуто не компилится пример, пишет:
Хотя development kit встал нормально…
g++ -o init.bin main.cpp
/tmp/cc7XKvnp.o: In function `main':
main.cpp:(.text+0x47): undefined reference to `FCGX_Init'
main.cpp:(.text+0xab): undefined reference to `FCGX_OpenSocket'
main.cpp:(.text+0xd2): undefined reference to `FCGX_InitRequest'
main.cpp:(.text+0xfb): undefined reference to `FCGX_FPrintF'
main.cpp:(.text+0x107): undefined reference to `FCGX_Finish_r'
main.cpp:(.text+0x113): undefined reference to `FCGX_Accept_r'
collect2: ld returned 1 exit status
Хотя development kit встал нормально…
Судя по гуглу проблема не редка на линуксе, зато нашёл вот эту библиотечку http://cryp.to/libfastcgi/
проверьте включение .h файла и библиотеки.
компилятор говорит что функции не найдены на этапе компиляции, значит он даже не нашел их объявления в .h файле.
компилятор говорит что функции не найдены на этапе компиляции, значит он даже не нашел их объявления в .h файле.
Делается это так:
g++ -o init.bin main.cpp -lfcgi++
т.е. указать что использовать либу для С++ если для С то без ++
Если после компиляции запустить и начнет ругаться на отсутствие либ, просто пролинкуйте их т.к. fcgi инсталится в /usr/local/lib
g++ -o init.bin main.cpp -lfcgi++
т.е. указать что использовать либу для С++ если для С то без ++
Если после компиляции запустить и начнет ругаться на отсутствие либ, просто пролинкуйте их т.к. fcgi инсталится в /usr/local/lib
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Apache, fastcgi и c++: «Hello, world»