Php vs c/c++

Уважаемые господа AWM'ы!
Прошу высказать ваше мнение по теме. Что же все-таки лучше? Что шустрее? Так же интересует мнение о целесообразности использования PHP Акселераторов и т.п. Тоесть, хотелось бы рассмотреть проблему в комплексе.
Спасибо.

по скорости
fast cgi
php
cgi
perl
etc

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

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

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

Раскладка будет примерно так (из того, что я пробывал на своем опыте)

1. бинарный апачевский модуль

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

3. php
3. cgi на языках С,С++

4. cgi на perl

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

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

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

P.S. помнится в споре perl vs php был приведен аргумент "а зато вы на php не сможете с com портами работать !"

Хотел чтото сказать
да Stek опередил ..
поддерживаю Steka

С++ для сложных задач
PHP для вывода динамических страниц + MySQL и не более

Я бы C++ применял только для киритических к скорости выполнения приложений, и писал бы в основном модулем к апачу. В остальных случаях PHP рулит.

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

хотя на C++ тоже бы не стал

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

Я понимаю, что все хорошо на своем месте. Если взять классический пример - CJ скрипт, что лучше использовать в этом случае? Т.е. с точки зрения производительности, если предположить что функционально скрипты одинаковы.

Основываясь не на теоретических умозаключениях а на опыте покалений я скажу ...
CJ на С++ производительней в разы ..

Да мне тоже так кажется. Хотелось бы послушать какие еще есть мнения.

Storm писал:

Основываясь не на теоретических умозаключениях а на опыте покалений я скажу ... CJ на С++ производительней в разы ..

имхо,
главный тормоз сиджа - это использование mysql
особенно в in и out
ну собственно их и желательно писать на си
остальное на производительности сиджа влияет не очень сильно

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

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

собственно таким образом все путние сиджи и написаны.

Гм... мой сидж на php выдерживает без проблем 100.000 запросов на IP III 1Ghz 512Ram

При весе страницы 150к , а у многих сиджей страница и 400к весит, то мы получ за день трафик
150*100000/1024 = ~ 14Gb в день.
Это значит что за месяц будет более 400 гиг траффика.
Что значит, скорее всего сидж будет стоять на дидикейте, который при теперешних ресурсах мощнее выше обозначенного компа.

А теперь смотрите, чем больше вы платите за дидикейт (а обычно это трафф), тем как правило мощнее комп там стоит. Так что все друг друга компенсирует без проблем.

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

На мой взгляд нормальный сидж, это сидж написанный на таким образом, где хранение данных происходит в базе, но рабочая (текущая) статистика хранится и осуществляется в памяти, и работает с ней отдельны запущеный демон, который каждые n времени скидывает в базу отчеты и при этом же строит внутри себя очереди для трейда.
В вэбе же у апача есть только один модуль - который не умеет ничего, как кроме обратится к демону и взять следующего.
И получите вы тогда на том же гигагерце по 400 запросов в секунду.

Только интересно, для кого актуальны такие нагрузки ? Наверно для единиц.

Stek писал:

На мой взгляд нормальный сидж, это сидж написанный на таким образом, где хранение данных происходит в базе, но рабочая (текущая) статистика хранится и осуществляется в памяти, и работает с ней отдельны запущеный демон, который каждые n времени скидывает в базу отчеты и при этом же строит внутри себя очереди для трейда. В вэбе же у апача есть только один модуль - который не умеет ничего, как кроме обратится к демону и взять следующего. И получите вы тогда на том же гигагерце по 400 запросов в секунду. Только интересно, для кого актуальны такие нагрузки ? Наверно для единиц.

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

кстати, вот еще интересный вариант без демонов и с mysql, идея не нова, но применений к сж не видел еще.

просто сделать открытый коннект к mysql в shared memory, ну или, еще лучше, пул открытых коннектов.

пусть программка(ведь скомпилированный C/C++ все-таки не "скрипт" ) при запуске проверяет есть ли пул, и если нету, то пусть создаст.
т.е. это получится просто mysql_pconnect из пхп, только грамотно написать надо.

тогда проблема коннектов к mysql(которые и отнимают большую часть времени) решена, а с появлением query_cache в mysql ver >= 4, скорость выполнения запросов должна также неслабо подрасти, ибо они все однотипные.

Stek писал:

Гм... мой сидж на php выдерживает без проблем 100.000 запросов на IP III 1Ghz 512Ram При весе страницы 150к , а у многих сиджей страница и 400к весит, то мы получ за день трафик 150*100000/1024 = ~ 14Gb в день. Это значит что за месяц будет более 400 гиг траффика. Что значит, скорее всего сидж будет стоять на дидикейте, который при теперешних ресурсах мощнее выше обозначенного компа. А теперь смотрите, чем больше вы платите за дидикейт (а обычно это трафф), тем как правило мощнее комп там стоит. Так что все друг друга компенсирует без проблем. mysql перед большинством сижных сиджей (а они появляются постоянно) кстати выигрывает тем, что его база оттачивается и вылизывается не одним десятком людей. Что существует нормальный апи, структура, софт который востанавливают базу при крахе. А кто знает устройство очередной крутой бинарной базы сиджа ? На мой взгляд нормальный сидж, это сидж написанный на таким образом, где хранение данных происходит в базе, но рабочая (текущая) статистика хранится и осуществляется в памяти, и работает с ней отдельны запущеный демон, который каждые n времени скидывает в базу отчеты и при этом же строит внутри себя очереди для трейда. В вэбе же у апача есть только один модуль - который не умеет ничего, как кроме обратится к демону и взять следующего. И получите вы тогда на том же гигагерце по 400 запросов в секунду. Только интересно, для кого актуальны такие нагрузки ? Наверно для единиц.

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


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

ну до полутора штук - это жестоко. Лучше переоценить противника, чем недооценить, т.е. при указанном лимите запросов в душе знать про возможный запас

По поводу коннекшенов ... для php использовать pconnect стойчески не советую. По поводу пула на сях ... может оно и так.

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

100к да, не показатель. Но на моем гигагеце in при тесте делал ~58к запросов за час.
Поэтому я просто взял 100к как красивое число. Я не спец в сиджах, и поэтому просто привел свое мнение, что часто дешевле наращивать технику чем быстродействие.
Это особенно интересно наблюдать, когда люди для сиджа с десятком тысяч хитов, ищут сидж, который "без байды должен пол лимона держать".

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

Понятное дело, что тем кто предоставляет хостинг с CJ выгоднее иметь более дорогое, но быстрое и качественное решение. А так, на простые виртуалы ...

Тут вот какое дело: CJ это довольно специфическая задача. В том смысле, что мы имеем дело с реальными людьми. Мне показалось, что переход на более быстрый скрипт дал прирост внутренней продуктивности на несколько процентов, не исключено, что и внешняя продуктивность подросла. Кроме того, как писал Alexus, скрипт быстрее отвечает на трейд, следовательно лучше разгоняется и держит трафф. Может для сиджа весом 150К это и не актуально, но и в этом случае хуже не станет.
Конечно, проще написать CJ на php (поскольку алгоритм трейда в существующих скриптах не идеален). Но такой скрипт не будет иметь коммерческого применения. А при идентичных функциональных возможностях лучше использовать более быстрый скрипт. Все упирается в затраты.

SadBoy:
Совершенно с тобой согласен.

Все очнеь сильно определеяется задачей, и способом ее реализации. Какие допущения могут быть реализованы в алгоритмах. У нас работает на дедикейте PHP CJ-подобный скрипт, и обрабатывает 1.5М хитов в день, и вполне может потянуть 2-3М.
Допущения:

mysql только для сбора статистики
cron обработка статистики
сбор статистики на основе вероятностных схем
....

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

Я согласен с Вовасиком, интернет-проекты очень маленькие по сравнению с каким нибудь десктопным приложением, поэтому их и удобно писаnь на PHP.