C++ для WEB?

Трава? :-)

ИМХО, твоя затея разве что в познавательских целях интересна.

Пофиг что - но пиши модулем к апачу.

Я на микроядерность собираюсь, а тут такое. Ну нафиг. Не сильно то и быстрее будет.

:)

нет. на самом деле все серъезно.

планирую обрабатывать большую нагрузку, а денег на крутые сервера нет.

поставлю у провайдера _один_ домашний ящик, что-то типа Athlon64x2, raid 0+1, 4G ram.

поэтому все должно быть оптимально

>домашний ящик, что-то типа Athlon64x2, raid 0+1, 4G ram

Нифигасебе домашний ящик!!! Да на такой тачке можно вообще не париться! Да и врятли твои способы будут хоть сколькобы быстрее, чем традиционные - особенно забавно упоминание про конект к БД))

ЗЫ А что ты имеешь ввиду под большой накрузкой?

про БД я имел ввиду вот это:

>. ГЛАВНОЕ: Максимальная производительность. Обработка запроса будет практически равна времени работы с базой

Ты же не числодроблением заниматься собрался? На задачах типа форума так и будет - Обработка запроса будет практически равна времени работы с базой.

> ЗЫ А что ты имеешь ввиду под большой накрузкой?

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

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

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

Буагагага!

в общем я тоже так думаю, но профилирование таких задач еще не делал, и как там дело обстоит в действительности не знаю. а может на базу идет только 70% времени?

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

может еще расскажешь, что google тоже на PHP пишет?

скриптовые ЯП для веба рулят потому, что:

1) ты можешь на лету переписать кусок кода прямо на сервере, нажать Ctrl+F5 в бродиле и изменения заработают сразу, без сборки/чистки/отладки

2) ты не ипешся с типизациями, указателями, не изобретаешь метод пузырька для каждой простой операции (превед, пасакакаль)

3) необходимые модули/классы скорее всего уже есть в интерпретаторе, либо доставляются прямо в диру сайта и одним движением подхватываются

4) если ты не спал сутки и вдруг очепятался твоя ошибка скорее всего не положит весь сервер

5) если уверен, что пишешь более производитлеьный код, чем у разработчиков интерпретатора, то, вероятно, не спрашивал бы про $subj

если ты чему и на учишся пытаясь реализовать сайт на плюсах, то это будет очень косвенно связяно с веб-программированием (например скорее всего ты будешь генерить и струячить html/js код прямо в стдаут или возмешься еще писать с нуля парсер шаблонов ?)

месье обкурился или просто стебётся?

/me хочет написать ос на lisp'e, особенно после косяка-другого.

На board.rt.mipt.ru вроде на плюсах форум (или на голых сях), и по слухам благодаря этому существенно меньше грузит сервер, чем раньше. Ничего невозможного тут нет.

> /me хочет написать ос на lisp'e, особенно после косяка-другого.

уже есть, emacs'ом зовется;)

> уже есть, emacs'ом зовется;)

хм. аки загрузчик - граб. mm и sheduler пусть сишными будут, фиг с ними. а в остальном очень даже =))

1. Достаточно большое время может тратится на генерацию HTML-я из шаблонов, как раз из за тормознутости интерпретирумых языков. Это где C++ может дать выигрыш в производительности. Ещё например трансляция с какого нибудь ббкода в хтмл. Больше в форуме каких то ресурсоёмких задач не помню. Ну ещё один большой плюс С++ будет в потреблении памяти, если нормально писать - памяти будет потреблять на пару порядков меньше, чем PHP/Perl.

2. Postgres имеет смысл юзать, если надо всякие сложные штуки обрабатывать, триггеры и тд, если вся работа с базой зключается в SELECT, UPDATE, DELETE, то postgres не нужен.

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

нуда, линукс - это по сути драйвер для железки, называемой, компьютер:)

Мужики я что-то не вкуриваю, что есть форум? Содрать пост со траничкой и запихнуть его в базу? И тоже самое что-бы все это показать. Ну собствествеено вы хоть на erlang'e hello word напишите, одна фигня будет. Какая разница на чем писать такую легкую задачу?

Гугл, по моему, на Java и Python, а вообще гугл большой и пишут там, наверное, много на чём :))

перед запихиванием проверить на безопасность, права доступа данного пользователя (есть ли вообще пользователь, не истек ли срок его сессии), потом все красиво(и удобно) показать, модератору повесить кнопки "удалить/зобанить" рядом с постом, пользователю поле ввода для поиска ну и т.п.

> На board.rt.mipt.ru вроде на плюсах форум (или на голых сях), и по слухам благодаря этому существенно меньше грузит сервер, чем раньше.

Не только по слухам :) Там внизу ссылка где можно исходники взять.

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

Как раз из-за наличия "компилируемости" он ОЧЕНЬ неудобен для веба

Почему?

Единственный теоретический недостаток - для упрощения развёртывания на сервере должен быть компилятор. Впрочем для единичного проекта даже это не обязательно.

Гы :)

> 1. Достаточно большое время может тратится на генерацию HTML-я из шаблонов, как раз из за тормознутости интерпретирумых языков.

Ну да, а вы думаете, что ИНТЕРПРЕТИРОВАТЬ шаблон средствами C++ будет быстрее ? всё-равно же упретесь в то что нужен ещё какой-нить механизм, вроде скриптового языка - и всё по новой :)

> большой плюс С++ будет в потреблении памяти

ну это бабушка надвое сказала - STL, динамика, упомянутое "метапрограммирование" - эффект будет не настолько значителен.

> трансляция с какого нибудь ббкода в хтмл

насколько понимаю на PHP Perl это делается через regsub? то есть вызывается php-шная функция, которая перелопачивает параметы для стандартной функции из libc(или нестандартной, но тоже С-шной); Дык вот на С++ всё будет точно также..весь выигрышь в скорости перелопачивания аргументов и вывода текста.

> если вся работа с базой зключается в SELECT, UPDATE, DELETE, то

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

Кстати, а вы не задумывались, зачем вообще появился PHP ? Отчасти затем, чтобы упростить и ускорить разработку при минимальных издержках по памяти и скорости - разработка того-же форума с теми-же базовыми возможностями (хотя-бы сесии, сжатие/криптование потока, интерфейс с web-серевером) на С++ займёт (польщу) раза в два больше времени, то есть будет в два-три раза дороже..

> Ну да, а вы думаете, что ИНТЕРПРЕТИРОВАТЬ шаблон средствами C++ будет быстрее ?

Да, я так думаю. Вы не согласны, что в подобного рода задачах С++ лучше PHP? Особенно учитывая то, что предел оптимизации у С++ куда больше, вплоть до ручного char* итерирования.

> всё-равно же упретесь в то что нужен ещё какой-нить механизм, вроде скриптового языка - и всё по новой :)

Это ещё зачем? Язык шаблонов и более-менее полноценный скрипт это две большие разницы.

> ну это бабушка надвое сказала - STL, динамика, упомянутое "метапрограммирование" - эффект будет не настолько значителен.

При чём тут STL? Вообще то STL очень быстр, и как правило ложится один в один аналогичному С коду. Метапрограммирование тем и хорошо, что (при разумном использовании) позволяет без вычислительных затрат получать удобный и безопасный языковой инструмент.

> насколько понимаю на PHP Perl это делается через regsub? то есть вызывается php-шная функция, которая перелопачивает параметы для стандартной функции из libc(или нестандартной, но тоже С-шной); Дык вот на С++ всё будет точно также..весь выигрышь в скорости перелопачивания аргументов и вывода текста.

не совсем, применять регэкспы для парсинга ббкода смысла особого нет, т.к. там фактически в основном простое сравнение строк.

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

Почему это? Разделение логики приложения на слои и всё. Не знаю, когда я писал форум на перле, никакого винегрета не было. Вполне допускаю, что более крупные приложения требуют от базы большего. Кстати по-моему 90% php-шных форумов и требуют вышеупомянутого функционала, и никаких хитрых триггеров не используют. Впрочем могу ошибаться.

> Кстати, а вы не задумывались, зачем вообще появился PHP ?

Насколько я помню, это был язык шаблонов для перлового движка :) Mason очередной :)

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

Не согласен. Единственное в чём выигрывает PHP - наличие библиотечных функций в базе языка. Но я уверен, что существуют готовые библиотеки на С++, которые предоставляют аналогичные возможности. Другое дело, что программистов, готовых писать форум на PHP больше, чем программистов, готовых писать форум на С++ :) Но автора темы этот вопрос наверное не очень волнует. А дороже он и впрямь будет, даже не в 2 раза, раз в 5 как минимум. Впрочем это вопрос, к программированию, как таковому, отношения не имеющий.

>Интересно услышать объективные замечания :)

Делай как модуль к апачу или как fastcgi сервер. Второе безопасней. Оба варианта весьма быстры.

Если важна производительность, выкинь SQL и попробуй BerkeleyDB, вот оно понастоящему быстро и писать под него просто.

Если C++ знаешь лучше чем питон, пиши на c++. Или возьми питон, сделай так-же fastcgi сервер на нем (есть бинарные, быстрые библиотеки) и используй вместо SQL базу данных BerkeleyDB, получишь очень высокую производительность и ненужно будет перекомпилировать каждый раз при изменении проект.

>поставлю у провайдера _один_ домашний ящик, что-то типа Athlon64x2, raid 0+1, 4G ram.

Хватит и дохлого селерончика с гигом оперативы и sata винтами в зеркале если использовать python или c++ с BerkeleyDB.

По крайней мере твоя конфигурация оптимальна для весьма мощного php хостинга.

> 1. Достаточно большое время может тратится на генерацию HTML-я из шаблонов, как раз из за тормознутости интерпретирумых языков. Это где C++ может дать выигрыш в производительности.

XSLT, ClearSilver. Быстрее "наколенке" не получится, уверяю (на XSL можно отдавать сотни запросов в секунду с одно машины, я точно знаю).

> Ещё например трансляция с какого нибудь ббкода в хтмл. Больше в форуме каких то ресурсоёмких задач не помню. Ну ещё один большой плюс С++ будет в потреблении памяти, если нормально писать - памяти будет потреблять на пару порядков меньше, чем PHP/Perl.

"На пару порядков" - это вранье. В разы - да, возможно - но если СУБД будет на этом же сервере, то это вообще неинтересно никому, сколько там апач занимает - 15 мегов или 60. Потому что потсгрес все равно жрет 4 гига ;)

> Если важна производительность, выкинь SQL и попробуй BerkeleyDB, вот оно понастоящему быстро и писать под него просто.

BerkeleyDB - ящик с граблями. Из них, безусловно, можно построить дом - но придется потратить полгода на разгибание зубцов.

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

Т.е. вещь, конечно, полезная - но только для очень дисциплинированных и опытных разработчиков. По нынешним временам проще взять SQLite.

А вот совет насчет FastGCI - правильный, это вполне нормальный способ писать вебовку на компилируемых языках.

И, да, еще есть такая вещь как CORBA ;-) Можно писать логику в виде сервантов, а представление - в виде тупых скриптов "пойди вон в тот сервант, получи от него данные, засунь в шаблонизатор". Я знаю некоторое количество проектов под _большой_ нагрузкой, которое именно так и живуёт.

> 1. думаю, что практически все время будет уходить на обработку запросов к базе.

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

> 2. Производительность/удобство Postgres vs Mysql vs Others для таких задач. Вообще сейчас работаю с Mysql, но хочу приучать себя к серъезным вещам, поэтому думаю заюзать Postgres.

Для форума - зависит от соотношения постингов/прочтений. Если это что-то типа лора, где много людей читает, и гораздо меньше пишет - то мускуль или даже sqlite. Если много писателей, много ролей, много разделов и сложные возможности - то, может быть, и постгрес.

Вообще - если задача "промышленная", а не делается ради самообразования - то надо брать то, что умеешь готовить. В противном случае - то, что не умеешь, дабы расширить сознание.

Оно будет КДЕшное или Гномье?

Вообще, мне не понятно каким образом будет достигаться производительность, если ты просто собираешся добавить к имеющимся тормозам ещё и тормоза/глюки своей проги? Если так востро стоит вопрос производительности, забудь про питон, а делай на сях (не ++), либо модуль к апачю либо свой сервер. Но я не верю что ты достигнеш производительности большей, нежели апач+модуль на сях. В компилируемости проблем не вижу, единственное что может навредить при таком подходе - длительность разработки из-за низкоуровневости сей и чреватость ашыпками, в основном незаметной сразу некорректной работой с паметью, из-за чего в своё время и отказались от такого подхода.

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

(1) на начальном этапе у меня не будет денег на добавления железа, поэтому C/плюсы будут присутствовать в любом случае для оптимальности.

(2) авторизация/кэширование/распределенность(обмен данными между серверами, синхронизация/балансировка - да все серъезно и все хочу предусмотреть ;) в любом случае будет на С

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

> например скорее всего ты будешь генерить и струячить html/js код прямо в стдаут или возмешься еще писать с нуля парсер шаблонов

про обработку шаблонов чуть ниже

сэнкс. стянул. там форум на плюсах. будет очень хорошим факом.

а я на тебя уже чуть-чуть наехал в другом трэде ;)

> 2. Postgres имеет смысл юзать, если надо всякие сложные штуки обрабатывать, триггеры и тд, если вся работа с базой зключается в SELECT, UPDATE, DELETE, то postgres не нужен.

думаю, там будут вещи сложнее примитивного функционала

postgres +1

> Ну да, а вы думаете, что ИНТЕРПРЕТИРОВАТЬ шаблон средствами C++ будет быстрее ? всё-равно же упретесь в то что нужен ещё какой-нить механизм, вроде скриптового языка - и всё по новой :)

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

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

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

> Кстати, а вы не задумывались, зачем вообще появился PHP?

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

> И, да, еще есть такая вещь как CORBA ;-) Можно писать логику в виде сервантов, а представление - в виде тупых скриптов "пойди вон в тот сервант, получи от него данные, засунь в шаблонизатор". Я знаю некоторое количество проектов под _большой_ нагрузкой, которое именно так и живуёт.

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

> Оно будет КДЕшное или Гномье?

;) это будет сервер. он отношения к UI не имеет.

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

"апач+модуль на сях" +1

> единственное что может навредить при таком подходе - длительность разработки

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

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

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

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

А по поводу производительности - у меня есть знакомый, который пишет онлайновую игру, у него на таком железе как у тебя одновременно играет > 1000 человек, работает форум и чат. Написано на смеси C++ и Perl, причем перла сильно-сильно больше. Хранение данных - BerkeleyDB.

Так что если ты не планируешь создать мегаресурс на миллион хитов в день - то тебе такой машинки хватит. Форум/блогхостинг для нескольких десятков тысяч человек, даже если ты напишешь все-все на пых-пыхе, работать будет более чем нормально.

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

Что ты вкладываешь в слово "много"? Я тебе по секрету расскажу, что статику такая машинка может отплевывать со скоростью сетевого интерфейса (в смысле, гигабит в секунду). При этом проц/диск будут нагружены несильно. База на этом же железе выдаст (на БД среднего форума - два десятка таблиц/единицы миллионов строк), ну, 50..500 запросов в секунду, в зависимости от кривизны проектирования.

Т.е. нормально сделанный традиционный (LAMP) форум на указанной тобой тачке способен обслужить где-то 20..100 запросов в секунду. Если много читателей/мало писателей (массово популярный блог) - то нужно генерить статику, и в этом случае умножь эти цифры еще на 5.

А 100 запросов в секунду в пике - это что-то типа 20 в среднем, т.е. 1,5-2 миллиона показов в сутки. Оно тебе правда надо?

Напичсать движек, работающий через CGI на С++ можно без проблем, так же как и на sh. Другое дело, что у автора треда в йуношеский максимализм взыграл. Чтобы движек жог, нужно его вместе с HTTP-сервером крутить модулем в ядре и СУБД туда же модулем загнать :)

> (2) будет висеть движок сервером, а к нему будет коннектиться и получать данные, например питон, который висит модулем в апаче,

Python и PHP - это интерпретируемые языки. Модули апача отслеживают обращение к скриптам и реализуют их интерпритацию аналогично интерпритатору, запускаемому из коммандной строки. После чего возвращают результат работы. С++ - это компилируемый язык. Ему интерпритатор не нужен. Кидаешь бинарь в cgi-bin и апач сам обрабатывает запрос к модулю, как к запрос на исполнение файла и сам возвращает результат.

> (3) сам спп-шный движок прикрутить модулем к апачу, чтоб сразу заюзать функционал апача, если он там нужен будет.

Какой функционал апача тебе нужен в движке?

> (1) на прямую обрабатывать http запросы, т.е. полностью все на плюсах

Чем тебе не нравиться апач? Чем тебе не нравится вариант с CGI?