CGI скрипты на С

Интересует данная тема. Пишу на perl'e но поговаривают что скрипты написанные на сях работают быстрее скриптов на perl'e. Потому можект кто владеет данной инфой, имеет смысл писать на с чтобы сократить нагрузки на сервак?

Зависит от того, что именно у тебя внутри CGI происходит. Если там в основном запросы к базам/обработки строк, то нет особого смысла - выигрыш небольшой - даже, я бы сказал, весьма спорный. Задачи, на которых C становится ощутимо быстрее, выходят за рамки того, что ты увидишь на большинстве сайтов.
Так что если тебе кто говорит, что его продукт написан на C, а значит, "хреначит со страшной силой" - не верь Вопрос только в том, как написан, а не в языке.

си на порядок быстрее. это факт, но вопрос совсем не в этом - писать на Си под веб очень сложно. всплывает куча работы, скрытой для php/perl/tcl разработчика. выделение памяти, конкатенация строк и прочая пурга. тут опыт нужен/важен.

тем не менее - есть масса готовых библиотек для работы с шаблонами, html, субд

qDecoder, sql-relay, template2doc
было бы желание

сэнкс,
опыт разработки на С есть, да это конечно геморнее, но вот может оно того и стоит.

сэнкс,
опыт разработки на С есть, да это конечно геморнее, но вот может оно того и стоит.

Любой CGI на Си быстрее перлового в 10 раз.
Хотя бы потому, что не запускается перл

bleed писал:

Интересует данная тема. Пишу на perl'e но поговаривают что скрипты написанные на сях работают быстрее скриптов на perl'e. Потому можект кто владеет данной инфой, имеет смысл писать на с чтобы сократить нагрузки на сервак?

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

А на счет геморойности написания... Ну моей маме очень геморойно водить машину. Ей проще на тролейбесе... (аналогия, думаю, понятна).

Grumbler писал:

Любой CGI на Си быстрее перлового в 10 раз. Хотя бы потому, что не запускается перл

Хуйня. Про разы особенно.

(я не спорю что быстрее, но про разы - хуйня)

кстати, использование fast cgi perl api нивелирует разницу почти к 0-ю, но мы говорим о чистом перле.

2perlmaster: может быть и в 10 раз . если брать те же регекспы, к примеру.
в общем случае разница незначительна, так как никто не требует от веб приложений real time времени выполнения

Grumbler писал:

Любой CGI на Си быстрее перлового в 10 раз. Хотя бы потому, что не запускается перл

ну это 0.005-0.02 секунды в среднем, не так уж и много, гораздо больше задержка при отфоркивании процесса апача для запуска этого самого интерпретатора.

Все зависит от того кто пишет,
и на сях можно угробить самую простую программу, вот к примеру :
{for(i=0;i<strlen(s);i++)} это самая жесткая ошибка

А вообще мой совет топик-стартеру (bleed) - если собираешься писать под WEB то берись за PHP. У PHP нет недостатка связанного с интерпретатором и соответственно нет задержки присущей перлу (а mod_perl жрет слишком много памяти), скорость работы PHP примерно такая-же как и у Perl.

PS: сам я любитель перла и еще год назад не сказал бы такого о PHP ;)

PHP действительно лучше, кроме того там есть PERL-реги и с "си" они очень похожи.

в пхп есть как pcre (perl compatible или как там их.. неважно) так и posix regexp-ы...
впрочем, и под си есть обе эти библиотеки.

Grumbler писал:

Любой CGI на Си быстрее перлового в 10 раз. Хотя бы потому, что не запускается перл

Хм.. Ну, если ты mod_perl используешь, то как раз наоборот будет. Интерпретатору не надо подгружаться. А CGI на C как раз и будет каждый раз грузиться. Во-вторых, в этом случае прекомпиляция perl'ового кода не происходит каждый раз - прекомпилированный код остается в памяти. В третьих, тем, кто сомневается в производительности perl'а, я бы рекомендовал на slashdot.org глянуть - сайт, с загрузками которого не сравнится ни один в эдалтной сфере, весь на активном контенте - и работает на mod_perl. Вот здесь код
http://www.slashcode.com/

Если уж говорить о максимальной производительности, то это не CGI никак, а "родной" модуль для сервера. Только проблема в том, что кривость небольшая - и сервак полег

Насчет PHP - я бы тоже подумал десять раз. Я уже имею опыт написания партнерки на PHP и второй раз я бы не взялся Более кошмарный для программирования язык еще постараться надо, чтобы найти. Никакой проверки типов переменных, проверки их объявления, кошмарный синтаксис классов. Сейчас вернулся на Джаву - чувствую себя сухо и комфортно У этого языка та прелесть, что если код хотя бы откомпилировался - то с вероятностью где-то 90% он заработает так, как предусмотрено. И средства разработки... ну, это отдельный разговор Но для небольших скриптов это, конечно, overkill.

Мое общее имхо по языкам такое

Маленькие страницы/скрипты - PHP или perl
Поболее (объемом в неск. тыс строк) - perl
Большие веб-проекты - Java
Где особо критична производительсность - модули на C

CGI на C... ну, не знаю. Разве что если достаточно большое для модуля, а код юзеру не хочется показывать Или надо ставить не только на дедиках, а и там, где рутового доступа не имеешь. И то хотелось бы, чтобы на сервере mod_fastcgi стоял, чтобы не сажать производительность fork'ами. Но и там свои геморрои...

Короче, под задачу надо выбирать, и под того, кто писать все это будет

Dr.Syshalt писал:

Насчет PHP - я бы тоже подумал десять раз. Я уже имею опыт написания партнерки на PHP и второй раз я бы не взялся Более кошмарный для программирования язык еще постараться надо, чтобы найти. Никакой проверки типов переменных, проверки их объявления, кошмарный синтаксис классов.

из всего сказаного правда только в убогой реализации ООП

sexvendor писал:

из всего сказаного правда только в убогой реализации ООП

PHP 5 не считается, поскольку еще не зарелизен и до этого далеко. И то даже там проверка типов производится только при передаче параметров в функции.

Кроме того, строгая типизация означает обязательную проверку типов, а не по принципу "хошь - используй, хошь - нет".

Dr.Syshalt писал:

PHP 5 не считается, поскольку еще не зарелизен и до этого далеко. И то даже там проверка типов производится только при передаче параметров в функции. Кроме того, строгая типизация означает обязательную проверку типов, а не по принципу "хошь - используй, хошь - нет".

строгой типизации нет, но есть
gettype()
is_null()
is_numeric()
is_long()
is_bool()
is_array()
и ещё несколько
а по поводу проверки на то была ли инициализирована переменная, есть isset()

всё относится к PHP4 и помойму даже к PHP3

что уж тут говорить, здесь нет той строгой типизации как в Java, но реализовать проверку на тип переменной, я думаю, не сложней чем организовать исключение в Java ;)

Dr.Syshalt писал:

Если уж говорить о максимальной производительности, то это не CGI никак, а "родной" модуль для сервера. Только проблема в том, что кривость небольшая - и сервак полег

т.е. ты предлагаешь писать спец. модуль апача, а не CGI скрипт?

begemot писал:

А вообще мой совет топик-стартеру (bleed) - если собираешься писать под WEB то берись за PHP. У PHP нет недостатка связанного с интерпретатором и соответственно нет задержки присущей перлу (а mod_perl жрет слишком много памяти), скорость работы PHP примерно такая-же как и у Perl. PS: сам я любитель перла и еще год назад не сказал бы такого о PHP ;)

не на PHP я наврятли перейду, если будут на то серьезные причины. Просто привык к perl, да и взможности мне его нравятся.

У меня просто стоит задача как максимально экономить ресурсы сервака, т.к. до этого я использовал виртуалы, там то не особо задумывался о ресурсах, если что саппорт пинал. А вот про свой сервак уже голова болит как сделать все по уму, чтобы не было перенагрузок там где их можно избежать, потому и поднял данную тему.

bleed писал:

т.е. ты предлагаешь писать спец. модуль апача, а не CGI скрипт?

Стоит на это обратить внимание. По крайней мере модуль дает максимальный набор возможностей. У тебя в модуле абсолютно все под рукой. Тем более, что писать модуль не на много сложнее написания CGI.

lega_cobra писал:

Стоит на это обратить внимание. По крайней мере модуль дает максимальный набор возможностей. У тебя в модуле абсолютно все под рукой. Тем более, что писать модуль не на много сложнее написания CGI.

хороший вариант, но к сожалению инфы по этому поводу не так много можно найти. Сегодня в билдере кое что откопал по этому поводу., надо попробовать.

bleed писал:

хороший вариант, но к сожалению инфы по этому поводу не так много можно найти. Сегодня в билдере кое что откопал по этому поводу., надо попробовать.

шутник, это документрировано по самое нехочу и есть на apache.org

bleed писал:

хороший вариант, но к сожалению инфы по этому поводу не так много можно найти. Сегодня в билдере кое что откопал по этому поводу., надо попробовать.

Начинать стоит с апачи 2 - там идея модулей причесана довольно-таки прилежно, писать модули соверешнно не сложно.
В принципе, что бы нормально писать модули, надо понять две опции. Во первых, структуру модуля (рыбу можно сделать при помощи команды "apxs -g" и поизучать другие сырцы), и идею, я бы сказал так - хуков (hooks) - которая даст тебе хорошее представление о том, что и как в апаче обрабатывается. Документации, действительно, не так уж и много. И в основном, на английском языке.

Ну а далее, зависимости от задачи, строишь свои модули для своего сервера. Наиболее типичные задачи - специальная аутентификация и авторизация (при этом ты просто забываешь фразу "стандартная авторизация через .htaccess", так-как строишь такую, какая тебе нужна), свой фильтр (при этом ты можешь вынести всю математику в свой модуль, написав собственные процедуры обработки на си, и вызывая их из html при помощи ключевых слов), либо свой хендлер, который будет выводить клиенту все, что ты пожелаешь при помощи динамических страниц.

Модуль дает еще целую кучу преимуществ, позволяющих существенно оптимизировать производительность сервера.

lega_cobra писал:

Начинать стоит с апачи 2 - там идея модулей причесана довольно-таки прилежно, писать модули соверешнно не сложно.

ни в коем случае !! согласен что модульный интерфейс сделан более грамотно, проблема в другом - модуль должен быть thread-safe, а это требует совершенно другого уровеня знаний, многие полезные не thread-safe библиотеки просто нельзя использовать. хотя для простеньких модулей вполне подходит.
Начинать нужно с apache 1.x, писать под него намного безопаснее, он стоит на большем количестве серверов и еще не скоро уйдет в историю.

lega_cobra писал:

Документации, действительно, не так уж и много. И в основном, на английском языке.

видимо я искал лучше . И на русском есть и даже в электронном виде я видел книжечку "Writing Apache Modules" - документировано по самое нехочу.

Цитата:

Модуль дает еще целую кучу преимуществ, позволяющих существенно оптимизировать производительность сервера.

и еще больше возможностей его завалить

Что-то мы отдалились от первоначальной темы

Каждый инструмент имеет свои плюсы и минусы. И для каждой конкретной задачи будут свои особенности и предпочтительный инструментарий.
Спор что лучше: лук или чеснок - ничего не дает

begemot писал:

ни в коем случае !! согласен что модульный интерфейс сделан более грамотно, проблема в другом - модуль должен быть thread-safe, а это требует совершенно другого уровеня знаний, многие полезные не thread-safe библиотеки просто нельзя использовать. хотя для простеньких модулей вполне подходит. Начинать нужно с apache 1.x, писать под него намного безопаснее, он стоит на большем количестве серверов и еще не скоро уйдет в историю. видимо я искал лучше . И на русском есть и даже в электронном виде я видел книжечку "Writing Apache Modules" - документировано по самое нехочу. и еще больше возможностей его завалить

Мелкое замечание - мы вроде как ориентируемся на профессионализм, а не на дилетантизм. Так-что безграмотность программиста никак не может служить характеристикой инструмента. Когда программист в качестве трудностей указывает, например, необходимость выделения пямяти под переменные, то о чем можно говорить дальше. Или рекомендации, типа "не ходи туда, сынок, там надо знания иметь, а мы все тут тупые, и это не для нас" - выглядят совершенно смехотворно.Это, как бы, социальное замечание.

По поводу документации - сравним ее объемы с количеством доков для того же PHP. И адекватно раздуплимся с терминами "полно" и "не много".