LINUX.ORG.RU

Разбитые файлы CGI по типу веб программирования


0

0

Ситуация такая, по воли работы с веб движками (СMS) частично изучил работу php. Но на данный момент как-то получилось, что увлекся системой linux. И так как часто работаю в шелле, решил попрактиковаться в написание своих мелких программ на более низких языках (остановился на С). Изучая на ранних этапах Си заметил схожесть (ну поверхностно) с php, что породило у меня мысль переписать свой сайт в cgi формат.

Я не зря написал предысторию, чтобы заострить внимание, что мое изучения программирования началось с php. Отсюда вопрос: Возможно ли написать и скомпилировать так cgi бинарник чтобы он по структуре напоминал файлы php. Ну то есть не весел бы мегабайт 20 одним файлов, а был разбит на мелки подфайлы по принципу php. И работал бы без интерпретации, ну по какому то типу include.

Суть удобство было бы то, что изменяя часть сайта не стоило бы перекомпилировать весь сайт и заливать потом 20 мегабайт одним файлом, а просто перекомпилировать ту часть (те файлы) и залить их, тем самым быстро обновив (по обычному принципу работы с php).

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

Наверное только подгружаемыми модулями (dlopen, dlsym и далее). И ещё: лучше заменить CGI на FastCGI.

Deleted
()
Ответ на: комментарий от Deleted

Да FastCGI тут более приемлемо.

Ну я так понял, практически то что я хотел возможно сделать?!

У меня еще появились некоторые уточнения: Возможно ли чтобы те бинарные файлы подгружались по выбору программы, ну то есть не все сразу в кучу?

Хотя для работы с FastCGI это наврятле будет рентабельно, создавая несовместимы процессы. Но насколько я уже знаю linux, в файловой системе есть биты для того чтобы скрипт после использования оставался в памяти. В связке апач + CGI или FastCGI - это будет работать?? То есть чтобы FastCGI или CGI брали файл уже с памяти, а не с диска?

Еще интересно будет ли перекомпилированные части (те бинарные файлы) совместимы с ранее другими файлами программы? Ну то есть тот момент когда мы что-то изменяем в сайте и заливаем некоторые измененные бинарные файлы? Точно не знаю может тут будет какая-то криптографическая несовместимость?

list2009
() автор топика
Ответ на: комментарий от list2009

>Ну я так понял, практически то что я хотел возможно сделать?!

А почему такое удивление ? Ядро умеет грузить модули, куча программ использует разделяемые библиотеки, некоторые программы поддерживают плагины — значит можно сделать.

>У меня еще появились некоторые уточнения: Возможно ли чтобы те бинарные файлы подгружались по выбору программы, ну то есть не все сразу в кучу?

Как напишешь, так и будут загружаться.

>Еще интересно будет ли перекомпилированные части (те бинарные файлы) совместимы с ранее другими файлами программы? Ну то есть тот момент когда мы что-то изменяем в сайте и заливаем некоторые измененные бинарные файлы? Точно не знаю может тут будет какая-то криптографическая несовместимость?

Если сам в API ничего не сломаешь, то конечно будут.

roy ★★★★★
()
Ответ на: комментарий от roy

Спасибо за информацию, а удивление было не потому что я сомневался в гибкости языка, а скорее сомневался в гибкости самой реализации cgi на apache...

Раз пошла такая пьянка... (с), завалялся еще вопрос: Относительно трудозатрат (количество кода и потраченного времени) и скорости, что будет лучше выбрать С или С++? Принципе волнует только производительность, так как переписывать буду движок очень очень долго и в свободное время в качестве укрепления знаний языка.

Почему такой вопрос, просто знакомый сказал что количество кода будет на С больше чем С++ приблизительно 1 к 1000 строк. Так ли это?? И насколько скорость работы С++ меньше будет (сам предполагаю что они относительно равны по производительности).

PS Принципе основная цель это производительность, на количество пользователей. А уж количества кода буду уменьшать самописными библиотеками на основе решений и чтений исподников php (если wiki не врет он на C написан).

Буду переписывать движок форума, исходниками поделюсь с сообществом ;).

list2009
() автор топика

Ну раз уж хочется CGI и на Си, делай отдельный бинарник для каждой страницы, да и усё. printf("Content-Type: text/html\n\n"); printf("<html><head><title>Hackir Vasya</title></head><body>Ja krut!!!</body></html>").

anonymous
()
Ответ на: комментарий от anonymous

да как реализовать это найду, это лишний тренинг для освоения языка. Меня сейчас интересуют технические вопросы (те которые выше). Да и для форума (да и для CMS) отдельный бинарник для страницы это не нормально, нужно динамично генерированы страницы с БД.

Бд менять не буду (mysql).

list2009
() автор топика

Ох, каждые полгода появляется человек, который пишет сайты на Си + CGI.

Хорошо хоть автор делает это для обучения...

anonymous
()
Ответ на: комментарий от anonymous

> Ох, каждые полгода появляется человек, который пишет сайты на Си + CGI. > Хорошо хоть автор делает это для обучения...

И то правда. Хотя мог бы и порадоваться за человека пытающегося перейти на светлую сторону силы. ;)

anonymous
()

Не забивай голову всякими модулями. Сделай /engine.cgi, на него каким-нибудь rewrite url-ом перенаправляй все запросы, и в нём уже решай, что за запрос и как его обработать.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Спасибо за поддержку,

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

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

Другое что меня привлекает это то, что для меня легче изучить досконально один язык и программить только на нем, чем держать в голове десятки синтаксисов и функций в голове, путаясь в будущем. Поэтому лучше затрахать себя Си кодом на cgi чем, забить голову и учить Perl, Phyton, php, Ruby...

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

Кодинг - это бодибилдинг для мозгов ;)

PS Народ, прежде чем забить топик флеймом, просьба, ответьте на мой предыдущий вопрос (продублировал ниже)

===========

Спасибо за информацию, а удивление было не потому что я сомневался в гибкости языка, а скорее сомневался в гибкости самой реализации cgi на apache...

Раз пошла такая пьянка... (с), завалялся еще вопрос: Относительно трудозатрат (количество кода и потраченного времени) и скорости, что будет лучше выбрать С или С++? Принципе волнует только производительность, так как переписывать буду движок очень очень долго и в свободное время в качестве укрепления знаний языка.

Почему такой вопрос, просто знакомый сказал что количество кода будет на С больше чем С++ приблизительно 1 к 1000 строк. Так ли это?? И насколько скорость работы С++ меньше будет (сам предполагаю что они относительно равны по производительности).

PS Принципе основная цель это производительность, на количество пользователей. А уж количества кода буду уменьшать самописными библиотеками на основе решений и чтений исподников php (если wiki не врет он на C написан).

Буду переписывать движок форума, исходниками поделюсь с сообществом ;).

List2009 (*) (17.01.2009 13:11:55)

=============

list2009
() автор топика
Ответ на: комментарий от list2009

>Другое что меня привлекает это то, что для меня легче изучить досконально один язык и программить только на нем, чем держать в голове десятки синтаксисов и функций в голове, путаясь в будущем. Поэтому лучше затрахать себя Си кодом на cgi чем, забить голову и учить Perl, Phyton, php, Ruby...

Это ты зря. Знать надо как минимум несколько языков, чтобы видеть разные подходы и уметь придумывать алгоритм.

>Си так же полезен и при работе и на самом линуксе, в будущем удобно будет писать небольшие скрипт программы

Небольшие скрипт программы на Си? Хм, они будут не очень небольшими, да ещё и писать будешь в разы дольше.

>Почему такой вопрос, просто знакомый сказал что количество кода будет на С больше чем С++ приблизительно 1 к 1000 строк. Так ли это?? И насколько скорость работы С++ меньше будет (сам предполагаю что они относительно равны по производительности).

1 к 1000 - это он загнул. В Си нет классов и прочего ООП, но при желании вполне можно его сделать. Это увеличивает костыльность и сложность кода, но не 1 к 1000 конечно. А без ООП сложно сделать что-то красивое в инете имхо.

Производительность - разница незаметна.

anonymous
()
Ответ на: комментарий от list2009

Забудь сразу про эту идею. Если волнует производительность, то C тебе в том виде в котором ты его хочешь применять тебе не поможет. Если уж задача о увеличении производительности у тебя возникнет (в чем я сомневаюсь), то подумай о разделении сайта на модули и почитай в гугле про построение высоконагруженных систем.

Обычно применяется многозвенная архитектура наподобие такого: proxy(nginx, etc)<->frontend(php,python,ruby,etc)<->backend(C,C++)<->хранилище. На каждом уровне работает несколько машин.

Reset ★★★★★
()
Ответ на: комментарий от Reset

ну на каждый раз на php грубо говоря уходить компиляция (интерпретация) кода, то есть затрачивается какое то время. Плюс сам язык на уровень выше, и в нем напичканы всякие динамичные типы переменных и прочих фишки, которые попадают под условие дополнительной обработки.

То есть логично, что обычный бинарник на С или С++ будет не в один раз быстрее всей этой проделки с php, то получаем неплохо прирост.

Конечно наверно легче будет сам php компилировать (говорят есть компилятор).

Но моя цель сохранить файловую структуру чтобы каждый раз компилить отдельные мелкие части, а не весь код и заливать на сайт по часу.

Но по идеи если рассуждать, (чисто по рассуждать) если php полностью написан на С то можно просто реализовать алгоритм перевода синтаксиса на уровень С, а потом в домашних условиях скомпилировать из С в байт-код. То есть я думаю по-любому перед тем как интерпретировать php в нативный код он преобразуется сначала до С (предположение), а потом в байт-код, если это верно то зачем лишнии затраты сервера...

list2009
() автор топика
Ответ на: комментарий от list2009

На твоих нагрузках не будет у тебя никакого прироста. Сколько запросов в секунду у тебя сейчас? 1000 есть? Если нет, то даже рыпаться не надо. А если есть, то надо смотреть что тормозит и разделять на frontend и backend, а не писать всё на C++.

Reset ★★★★★
()
Ответ на: комментарий от list2009

Ты кстати не забывай, что cgi каждый раз исполняется заново, поэтому это тебя не спасет. Оно у тебя будет загружаться 0.1 секунд а обрабатываться 0.00001 секунд. Смысл то какой?

Reset ★★★★★
()
Ответ на: комментарий от list2009

Мысли в слух: да вообще с условием популярности и количество исходников на php, если создать интерпретатора из php в C то: - Для материально корыстного человека это было бы неплохой бизнес. - Для истинных хакеров - всеобщее признание и уважение в мировом сообществе, ну и конечно страничка в вики рядом с Линусом ;)

Плюсы, - Повышение интерес к языку С/С++ как среди народа веб-разработчиков так и среди и начинающих, так и в маркетинговом мире (переписка магазинов и кодинг фичей для сайта на С будет в почете).

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

Вопрос в другом почему до это мало кто догадался (сейчас нарыл источники попыток просто перевода из php в С).

В общем кто меня опередит в написание интерпретатора из php в Си, просьба указать меня в строчках разработчиков как автора идеи ;) (просто ссылкой на эту тему, чтобы ресурсу было тоже полезно и народ знал где тусят русские (и не только русские) тру-кодеры ;) ).

list2009
() автор топика
Ответ на: комментарий от Reset

>Ты кстати не забывай, что cgi каждый раз исполняется заново, поэтому это тебя не спасет. Оно у тебя будет загружаться 0.1 секунд а обрабатываться 0.00001 секунд. Смысл то какой?

технология fastCGI держит процессы в памяти. Да и не долго я думаю модуль написать для апачь...

list2009
() автор топика
Ответ на: комментарий от list2009

>Повышение интерес к языку С/С++ как среди народа веб-разработчиков

Не нужен Си в вебе.

Разработка на си во многом очень долгая, учитывая всякие указатели и ручное распределение памяти - страницы замучаетесь делать.

А если делать компилятор пхп в си, то к определенному моменту либо перепишете заново пхп, либо сделаете яву.

Питон кстати в байткод компилируется.

anonymous
()
Ответ на: комментарий от anonymous

>Ох, каждые полгода появляется человек, который пишет сайты на Си + CGI.

И каждый раз одно и то же.

anonymous
()
Ответ на: комментарий от list2009

> Плюсы, - Повышение интерес к языку С/С++ как среди народа веб-разработчиков так и среди и начинающих, так и в маркетинговом мире > (переписка магазинов и кодинг фичей для сайта на С будет в почете).

Для начинающих это будет слишком усложнено, а для стандартных магазинов будет гораздо дешевле использовать perl/rails/php/java/etc.

> Вопрос в другом почему до это мало кто догадался (сейчас нарыл источники попыток просто перевода из php в С).

Может просто это никому не нужно? :)

user_undefined
()
Ответ на: комментарий от list2009

> Да и не долго я думаю модуль написать для апачь...

Боюсь, что долго. Да и апач сам по себе не является самым производительным решением. В общем не парь мозг не себе не людям, а изучай несколько языков и почитай как строятся серьезные системы.

Форум твой на Сях тут никому не будет нужен, поэтому можешь даже исходники не показывать.

Reset ★★★★★
()
Ответ на: комментарий от Reset

>Боюсь, что долго. Да и апач сам по себе не является самым производительным решением. В общем не парь мозг не себе не людям, а изучай несколько языков и почитай как строятся серьезные системы.

Пессимизма мне и так хватает. Тут скорее я вижу что кому-то лучше построить сложные системы (конечно хлеб для админов) и типа нужно безконечно оптимизировать и урезать код и т.п. Разве стоит мудится на кодом безконечно оптимизируя и урезая чем один раз написать и скомпилить?? Разве плохо иметь одноклассники на пентиуме 4, чем отдавать 2к за администрирование железа которое стоит тоже 2-4$к??

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

>Для начинающих это будет слишком усложнено, А кто их вообще заставляет? Или давайте все уйдем на framework'и?? Если бы был бы реализован компилятор из php в С, спрос к языку Си (и С++) был на порядок выше - это факт.

> а для стандартных магазинов будет гораздо дешевле использовать perl/rails/php/java/etc. Им похеру на чем, главное чтобы программист нормальный был и все работало. А там хоть на asm пиши =))

> Форум твой на Сях тут никому не будет нужен, поэтому можешь даже исходники не показывать Сколько раз говорили "Не говори за всех" или ты такой авторитет что управляешь мнением тысяч в сообществе??

В общем слезы такие как "Ох, каждые полгода появляется человек..." или "это не кому не надо" давайте лесом, я получил исчерпывающие ответы на своих вопросы, дальше мое дело. Всем спасибо, тему можно закрыть пока она не наполнилась нытьем и слезами - даешь Си в массы! =))

list2009
() автор топика
Ответ на: комментарий от list2009

>Пессимизма мне и так хватает. Тут скорее я вижу что кому-то лучше построить сложные системы (конечно хлеб для админов) и типа нужно безконечно оптимизировать и урезать код и т.п. Разве стоит мудится на кодом безконечно оптимизируя и урезая чем один раз написать и скомпилить?? Разве плохо иметь одноклассники на пентиуме 4, чем отдавать 2к за администрирование железа которое стоит тоже 2-4$к??

Понимаешь, во всех высоконагруженных проектах это и так есть.

Там используются решения на Си/С++/чём_угодно в виде различных демонов и бэкэндов. А морды продолжают делать на скриптовых языках. Во многом эту морду надо гораздо чаще менять и править, тут Си не подходит.

Выигрыш в скорости и ресурсах не будет заметен на мелком/среднем проекте. В вебе вообще скорость работы скрипта заметно меньше времени на передачу информации, работу сервера и прочего. Причем дело не в современных мощных компах - раньше было то же самое.

Писать сайт на си - то же самое, что большую десктопную программу на пхп.

По сабжу - пиши, обучение всегда полезно. Но 1) не забывай, что есть разные языки, и по-хорошему надо знать как минимум несколько. 2) Не пытайся выдать получившийся (надеюсь) проект за новое слово в веб-технологиях и прочее спасение человечества.

anonymous
()
Ответ на: комментарий от list2009

> Разве плохо иметь одноклассники на пентиуме 4, чем отдавать 2к за администрирование железа которое стоит тоже 2-4$к??

Эти все крупные порталы и так на хламе собирают, просто машин ставят сотни. Ты кстати не забывай что кроме масштабирования есть еще и такое понятие как надежность. Как ты будешь надежность осуществлять на одной машине?

Reset ★★★★★
()
Ответ на: комментарий от Reset

>Выигрыш в скорости и ресурсах не будет заметен на мелком/среднем проекте

А в реале можно реализовать большое количество фишек на сайте, не переживая что они потом в будущем станут результатои покупки дополнительного железа. Хобби не должно превращаться в работу. (понятие хобби так же не значит что у меня сейчас маленькие ресурсы). Могу много написать но скажу на уровне программинга - "Большая скорость обработки -> больше свободного времени процессора"

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

Именно поэтому первые мои вопросы были, о том чтобы реализовать бинарники так же по файлам как php, а не одним. То есть внес изменения, проверил у себя и залил 2-3 файла и все. Система работы таже, но результат того стоит.

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

>2) Не пытайся выдать получившийся (надеюсь) проект за новое слово в веб-технологиях и прочее спасение человечества.

Да это понятно. Но факт в том что и для Си должен быть стимулятор, а то так и буду потом все на мелкосовском C# или D писать. И соотвественно будут менегеры брать только таких программеров...

А чем популярней язык тем больше информации о нем, больше кода для чтения и изучений и больше вакансий.

>Ты кстати не забывай что кроме масштабирования есть еще и такое понятие как надежность. Как ты будешь надежность осуществлять на одной машине?

А что Си и MySQL не надежны??, или в чем именно вопрос надежности?? Ну поставь массив RAID, делай бекапы.

list2009
() автор топика
Ответ на: комментарий от list2009

> А что Си и MySQL не надежны??,

Нет

> или в чем именно вопрос надежности??

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

> Ну поставь массив RAID, делай бекапы.

Как оно тебя спасет в условиях 24/7 >1000 запросов/секунда? Пока ты будешь свой бекап доставать из шкафа знаешь сколько бабла за это время уже потеряешь?

Reset ★★★★★
()
Ответ на: комментарий от Reset

>Нет

аргументы

>Во всем, у тебя сгореть может все что угодно начиная свичем и заканчивая процессором. Про софтовые проблемы я уж молчу.

А если метеорит упадет, а если война начнется, а если интернет исчезнет - ты прав, пойду в балет.

>Как оно тебя спасет в условиях 24/7 >1000 запросов/секунда?

А что будет то?? или ты на PDP-11 сайты держишь?? Я вижу ты из тех людей которые представлят что 100% загрузка процессора равнасильна статусу "это очень плохо". 100% это информация означает что за "квант-времени работы процессора" он полностью работал все это время =)). Иди читай сколько информации может обработать современные процессоры. Единственным минусом как писалось выше это скорость работы сети (её будет не достаточно и процессор будет простаивать тогда когда бы он мог работать).

>Пока ты будешь свой бекап доставать из шкафа знаешь сколько бабла за это время уже потеряешь?

Ну если это все будет на обычном дедике с бюджетом однаклассников(маштабность), то у меня будет запас сверх прибыли который покроет все это время похода до шкафа, а не вылетит в убыток по сравнению если там аренда железа 2-5к$ (тут бежать надо до шкафа просто).

Да и по логике, восстановится быстрей то что проще, а не то что напичкано на десятки уровней серверов и имеет тонну настроек и софта.

И последнее, когда я писал про RAID я не просто сказал термин, я имел ввиду тот уровень, при котором отказ одного винчестера не вызовет падение системы (я не помню уровень давно не работал вроде 1). С бюджетом одноклассников (я имею масштабность) я бы тогда потратился даже на 3 винчестера, чтобы умирание 1 винта не вызвала бы проблему вообще (только бы скорость чтения уменьшилось бы с 3 раз (быстрее чем 1 винт), до 2 раз (быстрее чем один винт)).

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

list2009
() автор топика
Ответ на: комментарий от list2009

>Да это понятно. Но факт в том что и для Си должен быть стимулятор, а то так и буду потом все на мелкосовском C# или D писать. И соотвественно будут менегеры брать только таких программеров...

Си и так достаточно популярен для своих задач. На C# драйверы не напишешь особо. Так что сравнивать нельзя.

С твоим подходом не проще ли сайт вкомпилировать в апач?:)

anonymous
()

На самом деле такие вещи удобнее делать на интерпретируемых языках. Кроме PHP есть например Python. Писать веб на C пригодно например для web-интерфейсов к всякой интегрированной фигне. Если есть желание - посмотри ClearSilver и FastCGI. "Заливать 20 метров" не понадобится, в пол-метра влезет.

anonymous
()

И еще: писать web на C крайне непроизводительно. То что делается на Django дня за 2 на том-же C делается хорошо если за неделею. И с отладкой замучаешься. "Ошибка 500" будет потом являться в страшных снах.

anonymous
()
Ответ на: комментарий от anonymous

> И с отладкой замучаешься. "Ошибка 500" будет потом являться в страшных снах.

Можно узнать почему?? Php более не стабилен с этой точки зрения чем cgi, в php есть тонна процессов которые должны пройти и потом еще это все в html собрать и выдать, даже можно уронить апачь если пхп как модуль, а в cgi идет просто через stdin sdtout. Скорее если идет говно-код на стороне С, то в html будет просто вываливаться результат этого говно-кода.

list2009
() автор топика
Ответ на: комментарий от list2009

>Скорее если идет говно-код на стороне С, то в html будет просто вываливаться результат этого говно-кода.

Наивность. А segfault или ещё какая гадость, что типична для C-кода? В django, если используется встроенный отладочный сервер, исключение выдаст массу информации об ошибке. А случись гадость в C-коде мы получим сообщение в консоль (если руками запускали веб-сервер, я lighttpd использовал) что наша программа вылетела в segfault. И попробуй найди причину без журналирвания каждого чиха. У нас же никаких "строк", "списков" и прочих радостей интерпретируемых языков, кругом одни только указатели и malloc/free. И в отладчике особо не погоняешь.

Я с этим навоевался. А вы, очевидно, пока нет.

anonymous
()
Ответ на: комментарий от anonymous

я толком еще С не занимался, но помоему проблема решаема если чаще делать if else и вывод ошибки на экран с отстановкой (в stdout). Что вроде собственно интерпритатор php и делает.

Можно конечно и в торопях написать без лишних проверок, тогда и соотвественно только танец и бубен...

А ошибки класса segfault, переполнения буфера еще что там... о них просто нужно знать и помнить.

list2009
() автор топика
Ответ на: комментарий от list2009

>я толком еще С не занимался

Вот. Позанимайся. Желание очень быстро отпадёт, я гарантирую.

anonymous
()
Ответ на: комментарий от anonymous

>Вот. Позанимайся. Желание очень быстро отпадёт, я гарантирую.

Тут понятно, чем ниже уровень, тем больше проблем и натворить можно.

Наверное, просто нужно выработать в себе хорошие качества написания кода.

list2009
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.