ru.cgi.perl

 
 - RU.CGI.PERL ------------------------------------------------------------------
 From : Artem Chuprina                       2:5020/371.32  01 Sep 2000  12:07:22
 To : klum@nm.ru
 Subject : Re: CGI: C or Perl? Почти по Шекспиру... :)
 -------------------------------------------------------------------------------- 
 

 knr> Сижу тут и думаю - на чем писать CGI-ный код легко портируемый на Unix и
 knr> NT хосты, на Perl или на C - проект достаточно обьемный чтобы подробно
 knr> рассмотреть все за и против.
 
 knr> В С я могу соптимизировать код, потребление ресурсов процессора и памяти
 knr> что важно, т.к. хостер может обидеться на перегрузку системы.  И вообще
 knr> на С приятно писать. :) С другой стороны тут у меня проблемы с
 knr> портируемостью - я не писал программ под Unix (хотя достаточно большой
 knr> опыт программирования под Win) и вообще нет пока возможностей из за дикой
 knr> конфигурации системы, да и времени на изучение хотя бы Linux нету.
 knr> (только топать ногами не надо... :) )
 
 Hадеюсь, ANSI C благородный дон все-таки знает? Хотя тоже свои проблемы...
 Если ты работаешь с файлами, то в юниксах у тебя есть link и семантика rename
 не та, что в досе. Как с этим в NT, не знаю. Опять же, под виндой нету fork...
 
 knr> Я скачал gcc с http://sources.redhat.com/cygwin/ компилирующий Unix код
 knr> под Windows, с целью  контроля портируемости кода, кот. разрабатываю и
 knr> тестирую под Win/Apache.  Кстати, попутный вопрос - с помощью чего можно
 knr> под виндами скомпилировать *.cgi под юниксоиды, хотя бы под
 knr> intel-платформы ?
 
 Вообще gcc умеет кросс-компиляцию при наличии соответствующих библиотек и
 ассемблера (за цигвиновский не поручусь), но оно тебе надо?
 
 knr> Есть вторая, не менее важная проблема - на хостере обычно демон не
 knr> запустишь, или во всяком случае я себе не представляю как такой демон
 knr> будет отлавливать и исполнять запросы на мой виртуальный сайт на хостере,
 knr> предполагаю что это должно быть какое то расширение к www-демону хостера,
 knr> что естественно не каждый хостер позволит... А может быть есть другое
 knr> решение? Я бы с удовольствием узнал об этом.
 
 Так у тебя объемный проект или демон на хостере не запустишь? Идею держать
 объемный проект на халявном хостере рекомендую зарубить на корню - жить не
 будет. Кстати, какой демон и зачем?
 
 knr> Стандартное обращение к cgi предполагает загрузку в память исполняемого
 knr> кода, что для случая CGI, где несколько обращений в секунду может
 knr> привести к выделению больших ресурсов именно на процесс загрузки и
 knr> запуска еще одного процесса (на NT хосте это может привести к серьезному
 knr> торможению, не знаю как в Юниксах с этим делом).  При том, что время
 knr> исполнения скрипта может быть несколько десятков секунд (скрипт
 knr> связывается с другими серверами сети, так что это вполне нормально), так
 knr> что представляете, что в результате может получится. Мне кажется это
 knr> серьезная проблема, если нет - я буду очень рад. :)
 
 NT, разумеется, не юникс. У юниксов, где порождение нового процесса - действие
 стандартное, а не катастрофа, порождение нового CGI обычно довольно дешево,
 разве что он вызывается редко, и его реально считываемая с диска часть
 успевает покинуть дисковый кеш. Это, разумеется, касается только
 компилированных CGI, перл каждый раз устраивает продвинутую инициализацию.
 Зато на нем гораздо проще писать модули, чем на C (на C под апач тоже можно
 писать). Hо вот "время исполнения скрипта может быть несколько десятков секунд
 (скрипт связывается с другими серверами сети, так что это вполне нормально)"
 может быть фатальным. Если он на отдельном сервере и обращаются к нему раз в
 эти самые несколько десятков секунд или реже, то нормально, а если он под
 нагрузкой, то сервер умрет. Вне зависимости от того, как и на чем написан
 скрипт.
 
 -- 
 Счастливо!
   Ран.
 --- ifmail v.2.14.os-p7-tma3
  * Origin: MemoNet (2:5020/371.32@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор