LINUX.ORG.RU

c\c++ fastcgi фреймворки


0

0

начал изучать c\c++ fast_cgi

поставил на апач mod_fastcgi

конечно это не есть правильно

нужно использовать lighthttpd\nginx

но чисто для учебы - нормулик

почему начал изучать:

бешенная производительность

поясню:

1) заливаем на сервак сырцы и компилим их

2) открываем crontab и ставим наши бинарники на автоматический запуск после перезагрузки сервера

3) в htaccess указываем что наши бинарники - external сервера и добавляем им SetHandler fastcgi-script

4) вручную их запускаем итого мы получаем что наши скрипты в любой момент времени сидят в оперативке и ждут входящих соединений

каждому запросу не нужно ждать пока наш php\perl\java синтерпретирует и выполнит запрос

мы получаем полную мощь нативного с\с++

и никто никогда меня не убедит в том что php\perl\java а тем более ruby будут работать быстрее

единственное важное условие которое ложиться на программиста - следить за оперативкой! ведь если какой-то скрипт загадит оперативку - потребуется перезагрузка сервера.

написал привет мир

он читает html файлик 1 раз при запуске и отдает его любому конекту

если рассуждать что необходимо для стандартного проекта то тут возникают вопросы:

0) стартовая архитектура проекта типа zend framework

1) шаблонизатор.

2) стандартные функции php.

3) конекторы для работы с различными ресурсами

2:

из исходников php

из буста (boost.org)

из пекла (pecl.php.net)

этого явно достаточно

3:

для работы с базами данных - завались

а обычно кроме баз данных ничего и не требуется :)

на вопросы 0 и 1 я не знаю ответа

если кто знает - пишите!



Последнее исправление: puchuu (всего исправлений: 1)

>заливаем на сервак сырцы и компилим их

Сейчас тебе расскажут, почему так делать не нужно.

anon_666
()

>если какой-то скрипт загадит оперативку - потребуется перезагрузка сервера

Нет.

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

чтож, жду!

но от слов:

и никто никогда меня не убедит в том что php\perl\java а тем более ruby будут работать быстрее

я никогда не откажусь

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

это все конечно хорошо, но есть одно но. а как же ORM?

З.Ы. стыдно признаться, но я как-то написал cgi юзающий Qt, хыхы

antony986
()

омг!
я паходу нашел нечто нереально крутое!
как раз то что надо!
шаблонизатор для сишки! может быть настроен чтобы быть похожим на смарти!
http://ctpp.havoc.ru/algorithm.html
еще отпишусь как он подходит или нет

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

>я вот реализацию зенда для с\с++ как раз и ищу ;)

хыхы, повеселил, ладно не буду тебя расстраивать

алсо, ORM в зачатке можно увидеть в Qdjango, призвано напоминать django-orm, но...

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

эх видно не найду :(

ладно хоть пока шаблонизатор нашел
на винду он не станет
по крайней мере на винду 7 у меня не получилось поставить

пойду на мою виртуальную бубунту ставить :)

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

>2) открываем crontab и ставим наши бинарники на автоматический запуск после перезагрузки сервера

чо-чо? а сам mod_fastcgi уже разучился их запускать?

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

неа ты не поняль читай внимательней

external сервера

это значит что mod_fastcgi только прослойка между апачем и твоим бинарником он не обязан в режиме external ничего тебе запускать хочешь чтобы апач сам запускал - воспользуйся другим видом запуска бинарника мне так нравится!

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

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

но иногда (почти никогда) встречается страшная обработка данных
вот например была темка:
лень писать процедуру мускулу для мануальной сортировки результатов
и взял я да и склепал тупую сортировку с помощью пхп...
1-1.5 секунды сортирует ассоциативный массив из 500 элементов!
да ну нафик!
недавно сел и все таки процедуру мускулу написал
но все же мыслишка в голове засела - некоторые части сайта нужно писать на с\с++!

поэтому каментов типа «а почему бы не использовать такую-то технологию» настоятельно прошу не писать
мы конкретно рассматриваем то что указано в названии темы:
c\c++ fastcgi

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

поэтому каментов типа «а почему бы не использовать такую-то технологию» настоятельно прошу не писать мы конкретно рассматриваем то что указано в названии темы: c\c++ fastcgi

:)

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

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

честно говоря не очень понял камента
попробую пояснить:

Пишу CGI только на С

ну вот хорошо. я тоже так хочу. сейчас как раз это и <strike>гуглю</strike> учу

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

опять же хорошо.
но вы сделали то что уже готово давно:
http://pecl.php.net/ - я ссылку давал
это набор велосипедов которые реально поддерживаються людьми

Основную работу стараюсь переложить на клиента (Javascript), а серверный CGI лишь отдает нужную информацию

КЭПом подрабатываете? нэ?

Не знаю, зачем вам понадобился фреймворк для разработки сишных CGI

http://ru.wikipedia.org/wiki/Фреймворк
ты с зендом знаком? в огромных проектах участвовал?
если б да таких бы вопросов не задавал

еще раз озвучу пункты по которым я ожидаю ответов:
0) шаблонизатор (претендент ctpp)
1) фреймворк типа зенд

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

http://pecl.php.net/ - я ссылку давал

Так там же пыхпых.

ты с зендом знаком? в огромных проектах участвовал?

нет. нет.

Объясните мне, чем «огромный проект» вроде того же KDE отличается от «огромного» веб-проекта? Вам никто не мешает использовать те же технологии. Кроме того, при разработке CGI связка с web занимает меньше всего времени. Больше всяких «закулисных» работ: базы данных, оборудование, вычисления...

А «морду» пишут-то на html+javascript - а для этого уже чего только не понапридумывали.

В общем, сдается мне, проблема надумана.

Eddy_Em ☆☆☆☆☆
()

У кого-то каша в голове. Не надо мешать в одну кучу PHP/Perl/Python/Java.

Я не знаю насчет PHP (IMHO, он действительно убог), но вот насчет Java

каждому запросу не нужно ждать пока наш php\perl\java синтерпретирует и выполнит запрос

что такое JIT-компиляция слышали ?

мы получаем полную мощь нативного с\с++

JNI позволяет использовать C-шные модули, если очень нужно.

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

единственное важное условие которое ложиться на программиста - следить за оперативкой! ведь если какой-то скрипт загадит оперативку - потребуется перезагрузка сервера.

Garbage Collector JVM избавляет от такой необходимости

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

думаю просто топикстартер идет не в том направлении - вместо того чтоб
1. начать использовать фастцги на php (или на чем он там пишет)
2. начать переписывать критичные участки кода с php на C/C++
хочет написать все с нуля на «кошерном» ЯП.
преждевременная оптимизация - корень всех бед.

ЗЫ. для парсинга входящих http-запроса есть cgicc, даж обертка для использования с fastgci есть.

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

>>что такое JIT-компиляция слышали ?
знаю я это
жаба самый быстрый интерпретатор
без вопросов
но никогда не сравниться с нативным кодом на с\с++
доказательство - нетбинс
открываеш крупный проект - можно идти на 5 минут пить чай

JNI позволяет использовать C-шные модули, если очень нужно.

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


знаю я всю эту фигню и использую
но от этого практически ничего не меняеться

Garbage Collector JVM избавляет от такой необходимости

ага и именно поэтому в том же нетбинсе раз в 5 минут бывает притормоз
я разрешил нетбинсу жрать 1 гиг оператики
и что? без толку! как тормозил так и тормозит! все этот ваш ссаный колектор!
я уже лучше буду беспокоиться о памяти ручками чем доверять всякому уг

а сейчас о джаве идет разговор?
задолбали тыкать другими технологиями!
когда название темы читать будем?

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

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

2. начать переписывать критичные участки кода с php на C/C++

хочет написать все с нуля на «кошерном» ЯП.


преждевременная оптимизация - корень всех бед.


полностью с тобой согласен насчет того что сейчас нужно оптимизировать только части кода
но я решил заглянуть дальше
есть ли способ писать все тотально на с\с++
это что наказуемо чтоли?

если я увижу что есть возможность писать все подчистую на с\с++
то действительно начну писать
при условии что у заказчика найдуться столько денег чтобы это оплатить ;)

ЗЫ. для парсинга входящих http-запроса есть cgicc, даж обертка для использования с fastgci есть.

спасибо за очень дельный совет! =)

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

>>поэтому каментов типа «а почему бы не использовать такую-то >>технологию» настоятельно прошу не писать

мы конкретно рассматриваем то что указано в названии темы:

c\c++ fastcgi


читать умеем-с?

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

вы меня не поняли.
судя по моему опыту проблемы бывают не от того какой инструмент используется, а от того «как» он используется.
т.е. можно на яве написать так, что в GC будет сваливаться куча хлама и все будет тормозить (классический пример - обработка больших строк при помощи конкатенаций и сабстрингов), а написать так, что миллионы памяти выделяться не будет, зато будут использоваться разные встроенные кеши, и в итоге у вас получится быстрее, чем то же самое на C/C++ (по крайней мере за одинаковое время разработки).
тот же апачевский fileupload на яве под томкатом, по моим ощущениям, на больших файлах работает быстрее cgicc, написанном на кошерном c++ и запускаемый под lighttpd.

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

отстань от меня плс ты мне подсовываеш какое то скромное подобие пыхи

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

это вы меня не поняли
по вашему комментарию видно что вы сами ничего серьезного не писали на джаве

да я видел дурацкие тесты и сравнения с\с++ и джавы
о чем можно говорить?
чел умеет писать на джаве но на с\с++ просто нублоид полный
и по его тесту получалось что джава быстрее с\с++
вывод: руки у него кривее на с\с++ чем на джаве!

самый лучший вариант вообще - это с#
и руки нужны средней ровности и всегда эффективно получится
но - только под винду

все! заканчиваем про другие технологии а также про «как» они используются
вам задают конкретный вопрос: fastCgi
выводы сам сделаю!

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

>и взял я да и склепал тупую сортировку с помощью пхп...

1-1.5 секунды сортирует ассоциативный массив из 500 элементов!


http://ru.php.net/asort
http://ru.php.net/uasort

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

но все же мыслишка в голове засела - некоторые части сайта нужно писать на с\с++!


Если это так критично, кто мешает писать С/С++ модуль под PHP/Python/Ruby? Ну а под Java - обычно смысла нет, скорость всё равно сравнимая будет.

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

>и что? без толку! как тормозил так и тормозит! все этот ваш ссаный колектор!

Боюсь, что gc() тут совсем не при чём :)

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

!!!!!!!!!!!!!!!

поэтому каментов типа «а почему бы не использовать такую-то >>технологию» настоятельно прошу не писать

мы конкретно рассматриваем то что указано в названии темы:


c\c++ fastcgi


читать умеем-с?

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

> мы получаем полную мощь нативного с\с++

и никто никогда меня не убедит в том что php\perl\java а тем более ruby будут работать быстрее


поржал

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

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

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

>алсо, ORM в зачатке можно увидеть в Qdjango

Кстати, лет бы 15 назад я б ORM на Си/Си++ сделал бы, думаю, без проблем. Немало тогда ковырялся с кодогенерацией в рантайме. И именно на этих языках, напрямую работающих с памятью, проблем бы не было совершенно.

Но поезд Си/Си++ в этом контексте, походу, ушёл :)

KRoN73 ★★★★★
()

Денис Попов, перелогиньтесь!

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

Но поезд Си/Си++ в этом контексте, походу, ушёл :)

Почему же ушел? Си очень удобно использовать для разработки CGI, которые должны производить сложные математические расчеты, управлять железом, или просто удовлетворять повышенным требованиям к скорости.

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

он, по-моему, про кодогенерацию в рантайме.

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

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

Согласись, это «немного» не похоже на задачу генерации хтмл, которую пытался решить ТС.

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

>Си очень удобно использовать для разработки CGI, которые должны производить сложные математические расчеты, управлять железом

Лично я бы начал задумываться о Си только при необходимости управления железом.

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

По-моему, ему как раз генерация html особо и не нужна была. Я, честно говоря, не вижу смысла генерировать код из CGI, если все можно сделать средствами Javascript: делаем заготовку веб-страницы, пишем скрипты, которые посредством POST-запроса получают нужные данные, выполняют анализ полученных данных и изменяют внешний вид странички. Этот способ к тому же позволяет экономить драгоценный трафик.

Вот например, для наглядного отображения распределения температуры в помещении можно генерировать изображение на сервере и отдавать клиенту, но если тот захочет повернуть/изменить масштаб и т.п., придется гнать еще одну картинку; при моем подходе клиент забирает с сервера SVG-шаблон, скрипт получает значения температур в текущее время и рисует всю картинку. Обращений к серверу - минимум (первый раз - при загрузке, а затем раз в 5-10 минут для обновления показаний датчиков).

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от ef37

Лично я бы начал задумываться о Си только при необходимости управления железом.

А я именно из-за железа и начал писать сишные CGI. А потом понравилось, и я понял, что можно обойтись «голым» html+javascript с сишными CGI (а иногда вообще можно генерировать часть данных в веб-странице «на лету» при помощи SSI).

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

>Си очень удобно использовать для разработки CGI, которые должны производить сложные математические расчеты, управлять железом

Где в этих областях место для ORM? :)

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

>дотнет это вещь

дрель - это вещь, да? это да, но нет!

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