Хотелось бы узнать ваше мнение с плюсами и минусами.
Спасибо.



Это сообщение отредактировал(а) isergey - 5.4.2009, 21:58

isergey, пиши на том, в чем лучше разбираешься. 
Хотя такие проекты как Вконтакте, Одноклассники написаны на PHP

Добавлено через 1 минуту и 5 секунд
Хотя не зарекайся от того, что именно твой проект может стать высоко нагруженным.

isergey, 

а тематика проекта какая *? 

в чем наблюдается его нагруженость *? 

ну если не секрет *    

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

Кстати про одноклассники и в контакте. Все эти проекты изначально были написаны на коленке за 2 ночи и не подразумевали такое количество посещений. И то что там используется миллионное оборудование говорить наверное тоже бессмысленно. Хотелось бы найти оптимум затраты на аппаратную часть/производительность. 

Это сообщение отредактировал(а) isergey - 5.4.2009, 21:06

isergey, 

В большинстве (но не во всех) высоконагруженных проектах основная нагрузка ложится на БД.

Потому начинать надо с выбора БД и ее проектирования.

Как раз таки наоборот.
http://news.finance.ua/ru/~/1/0/all/2008/03/01/119989

isergey, находясь в разделе по PHP очень наивно создавать такие опросы. Логичто что мы ответим php =)

enof, 

Кому он сейчас принадлежит, и как он создавался - две разные вещи.

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

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

isergey, не очень правильный подход устроить голосования в РНР разделе.

Работаю в крупной компании, и здесь мы пишем в основном на asp.
Все это обьясняется скоростью, защещеностью, возможностью подключения библиотек, а так же перспективами на будущее. Т.е. php как таковой в будущем врядли будет поддерживаться, а asp будет.
Это не мои слова это слова аналитиков, в том числе из корпорации microsoft.

Согласен с Vasay:

Работаю в крупной компании, и здесь мы пишем в основном на asp.
Все это обьясняется скоростью, защещеностью, возможностью подключения библиотек, а так же перспективами на будущее. Т.е. php как таковой в будущем врядли будет поддерживаться, а asp будет.
Это не мои слова это слова аналитиков, в том числе из корпорации microsoft.

Согласен с Vasay:

поддерживаться в вашей компании? она сама решает
ессно, а что ещё мог саналитировать производитель .net?

Несмотря на все недостатки PHP, в будущем этой технологии я уверен куда больше чем в будущем .NET для web.

Да, смотря на PHP с высоты знания Java, я воспринимаю его как ребенка, только что вставшего на ноги - еще совсем недавно PHP полностью оправдывал свое название (Personal Home Page), так как не имел даже нормальной среды разработки с нормальным отладчиком. Однако он был прост в освоении и, что немаловажно, не требовал больших финансовых затрат на хостинг. Миллионы людей по всему миру для осуществления своих "гениальных" идей брали именно PHP. И некоторые идеи оказывались действительно Гениальными. Как следствие мы имеем суперпопулярные проекты на PHP. Естественно, столь популярная технология не могла не развиваться - появились фреймворки, многие IDE стали поддерживать разработку на php,  появились специализированные IDE. И вот ребенок уже твердо стоит на ногах и, при поддержке миллионов поклонников, готов идти к своему светлому будущему 

А что же с .NET для web? Это дитя растет, находясь в ежовых рукавицах своего родителя. Который полностью определяет путь его развития. У него гораздо более высокие цели чем у PHP - корпоративный рынок. На массовом рынке делать ему нечего - для простого человека иметь дело с .net слишком дорого . Однако и на корпоративном рынке все не так радужно - место под солнцем уже занято. Тут правит бал Java, поддерживаемая как и сильными мира сего (ibm, Oracle...) так и народом (опен соурс сообществом). 

Есть еще момент - направления, в котором корпорации развивают свои продукты направлены на скорость разработки (я уже писал выше, про то что проект типа "однокласники" с применением современных технологий можно сделать чуть ли не с помощью мышки), но в погоне за скоростью разработки напрочь забыли про пользователя. Проекты созданные с помощью современных  фреймворков, таких как JSF , просто не юзабельны (как подобный фреймворк называется у MS - не знаю, знаю что с его помощью сделана админка GoDaddy.com - отличный пример издевательства над пользователем). Но тут, благодаря поддержки опен соурсе сообщества, у Java есть альтернативы, а у .NET, за исключением некоторых портов с Java, их нет!

Так что, чтоб не говорили аналитики из Microsoft, положение в web у них не завидное.

Соглашусь с Vasay.
Вот именно поэтому что Net  в ежовых рукавицах, он до сих пор не развился должным образом.
А PHP как опенсоурсе, поэтому он очень распространен. Однако вы не забывайте про могущество корпорации microsoft... Они держат очень какую большую долю рынка комп технологий и программного обеспечения. Я конечно не затехнологию net(совсем мне не нравиться она, я программлю на PHP) но увы, будущее не загорами, и microsoft делает гигантские шаги чтобы внедрить в массы технологию net. Увы статистика интернет приложений показывает то, что .NET технологии продвигаются и довольно таки неплохими темпами(конечно microsoft хотела бы намного быстрее эти темпы)... так что можно сделать трезвые выводы...

Это сообщение отредактировал(а) bazzjr - 7.4.2009, 16:40

ну и пусть продвигается нам то что? пока жив разработчик, есть люди которым он нужен (РНР) то он и будет развиваться. тем более .нет можно использовать только на платформе Win, и то тока под IIS (могу и ошибаться). 





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

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

Добавлено через 2 минуты и 42 секунды

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

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

Насчет "библиотек" и "скорости выполнения скриптов", могу сказать одно:
В ПХП приложениях (по крайней мере я) не видел сколько нибудь мощьного интерфейса с всякого рода возможностями работы с окнами, т.е. этакую маленькую windows. А вот .НЕТ технологиях я видел, и сам лично ее юзал, и очень даже мощьно я скажу. 
1. Перспективы заключаются в том, что у НЕТ есть неоспоримые плюсы по отношению к РНР, какие, можно почитать в нете(инф-ции предостаточно).
2. Многих кого я знаю работали впрошлом с РНР, и перейдя на НЕТ говорят, что уже никогда не буду программить на РНР (НЕТ лучше говорят).

ИМХО работать можно и на барсике если умеешь.



ну и зачем нам форточки в интернете? 

даже если так сильно приспичило то дизайнер то на что?



приведи их сюда

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



Скажем так - они вообще в разных весовых категориях. .NET ориентирован на энтерпрайз рынок, где php действительно не место (пока). Вот только что .NET может противопоставить Java, гораздо более богатой фреймворками и, самое главное, являющейся родной технологией для производителей железа - только IBM-у принадлежит 31% рынка серверов, еще 11% SUN-у! А заказчики обычно покупают не железо, а программно-аппаратные решения. 



И кто (кроме MS) будет применять Silverlight в серьезном проекте, когда он не работает  во всех браузерах и не на всех системах?  

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

Тему еще не перенесли?

s0lman прав. Теме самое место в "Религиозных войнах", а не в "РНР: Общие вопросы" 

Я не стал отвечать на опрос. ИМХО, язык тут ни при чем. Как тут уже говорили, основная нагрузка ложится в любом случае на базу данных. Поэтому, больше важна архитектура, нежели язык, с помощью которого ее реализовали.

это только в случае простого CRUD-a, если вся логика сводится к вызову соответствующих SQL запросов и геренации html
если происходит что-то более сложное и нетривиальное, то ИМХО язык важен  

Разумеется. В таком случае, не вижу проблемы, что бы не использовать под конкретную задачу - конкретное средство. К примеру, если я пишу сервисный скрипт, который должен обойти файловую систему и, например, сконвертить картинки в определенный формат: я не буду это писать на PHP, я напишу это на шеле - быстрее и удобнее в сотни раз.

php грузит сервак хоть mod_php, хоть FastCGI  
можно попробовать Gallery2, IPB, type3, etc  

а perl в CGI заметно что не так, не забито все по ресурсам,  вот можно mod_perl + C/С++ (можно через JIT)

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

Это сообщение отредактировал(а) gcc - 10.4.2009, 18:42

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

isergey

CGI на C++ например, Apache Modules 

А вообще почему перл не указан? По моему это самый высокопроизводительный вариант.

Это сообщение отредактировал(а) azesmcar - 10.4.2009, 22:59

Какая напрочь разница?
Даже тормозной ROR не даст проигрыша, т.к. проигрыш на БД ляжет.

Добавлено через 1 минуту и 26 секунд
 И каким образом тут важен язык, если все равно будет обращение к либе на C(в подавляющем большинстве случаев)? =)

А что тут голосовать, если всё ясно и однозначно:
С++ + CGI  

C++ надо использовать, PostgreSQL и библу XSLT.

 Ты пишешь на C++ быстрее, чем я на PHP при одинаковом качестве? Что-то не верится =)
P.S. я юзаю к тому же и спец. фреймворки - ZF тот же.

nerezus

Скорость разработки приложения разумеется упадет, но речь шла о скорости работы приложения а не о скорости разработки. А тут однозначно компилируемый код - быстрее интерпретируемого. Плюс оптимизация компилятора С++.
Есть даже библиотеки для разработки веб приложений на C++, они значительно повышают скорость разработки. Хотя думаю по любому на ПХП быстрее. А из интерпретируемых как я сказал если не ошибаюсь перл самый быстрый.

Это сообщение отредактировал(а) azesmcar - 24.4.2009, 10:37

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

Кстати, по моему php не имеет нормального connection pool-а для работы с БД?

Есть pconnect, на это, вроде, не совсем то да и работает не во всех конфигурациях php.

Т.е. PHP при большом количестве запросов к бд будет создавать на нее дополнительную нагрузку.




Совершенно не однозначно. 

 

Добавлено через 1 минуту и 58 секунд
Интерпретатор написан компилируемым языком и это дополнительное звено в работе программы. Быстрее он никак не может быть.

 По стоимости на проект под $2k на пхп(для примера) он будет стоить под все 10. А теперь посчитаем, чего стоит докупка железа на период в год(для примера). Меньше этой разницы ;)
Так что производительнее в этом плане будет пхп(если разницу цен на аренду дом. машин потратить).

 +1. Пара сотен раз разницы в скорости на логике почти не заметна.

 Мсье не умеет правитть конфиги, чтобы работало в его конфигурации?)

azesmcar, 

Java и .NET, Perl, Python  перед выполнением будут скомпилированы. .NET еще и сохранит результат до следующего запуска.

Да...а процесс компиляции - требует времени. И по любому это нагрузка на сервер. Есть еще накладные расходы..если хотите поспорить поковыряюсь, но вы же не пытаетесь сказать что Джава быстрее С++? Пройдемьте в религиозные войны  
Компилируемые программы лишены этих недостатков (хотя у них есть свои, но это уже отдельная тема).


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

А так - на С++ выйдет медленее разумеется. Не настолько насколько ты описал конечно (в 5 раз) при наличии хорошей библиотеки CGI но все же медленее 

Это сообщение отредактировал(а) azesmcar - 24.4.2009, 15:21

ааааа..мы уже там  

pconnect, если я не ошибаюсь, работает только с апачем и только в том случае, если php установлен как модуль. Да, это самая распространенная, но не единственная конфигурация. 



Тут все не так просто.  Если вы предлагаете писать cgi на с++ то (я могу быть где-то не прав)

1. На каждый запрос к вебсерверу будет запускаться новое cgi приложение. (в случае Java или .NET - приложение запускается один раз)
2. Вытекает из первого - у cgi будут проблемы с поддержкой сессий, транзакций, да и соединения к БД придется создавать каждый раз заново.
3. Скорость будет во многом зависеть от кривизны рук программистов, писавших те или иные используемые нами модули (такие, как  RegExp)

можно подгрузить к апачу ДЛЛ-ку, и она будет висеть там до скончания веков, ничего не будет запускаться заного.
возможно это называется по другому

нет, не будут..я писал библиотеку для разработки CGI. Никаких проблем с сессиями не имел.

вот это точно сказано  

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



Да можно вообще обойтись без апача. Написать свое приложение, которое будет висеть демоном и слушать 80 порт.   Вот только, оценит ли заказчик ваши старания?

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

azesmcar,
 

Но подобные вещи (вебсервера под конкретное приложение) существуют.

Можно так же сказать, что писать веб приложении на c++ cgi тоже несравнимо тяжелее, чем делать это, например, на j2ee.


п.с. +1 за подпись

Цитата

24 апреля - день памяти жертв геноцида Армян в Турции. Вечная память

Помним!



Это сообщение отредактировал(а) Vasay - 24.4.2009, 16:47

Vasay

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


спасибо  

Google хочет убыстрить Python в 5 раз быстрее  http://www.opennet.ru/opennews/art.shtml?num=20981

нашел модуль для многопоточной работы с СУБД, надо будет посмотреть, написано ускоряет
http://search.cpan.org/~darnold/DBIx-Threa...BIx/Threaded.pm

интересно, есть ли Framework на С++  для веб? такой как этот Catalyst

угу, вот и я на http://vingrad.ru опубликовал задание по разработке такого веб-сервера на ява. Думаю, что ява должна быстро работать. Демон будет в памяти висеть все время и слушать на таком-то порту.

http://www.webtoolkit.eu/wt

а MVС есть? 
в этом HTML разметки зачем ставить в код? 

 Т.е. программу на C++ мы компилировать не будем? =)

 На логике не медленнее. См. в раздел джавы, там были тесты.

 А ты умеешь только в CGI конфигурировать?
Хочешь, научу подключать как модуль или как fastcgi? За пиво )

 Именно. И эти либы одни и те же для пхп и для C++. И основной расход именно на них. Если не брать внешних факторов.

И разница в скорости в несколько сотен раз не существенна для логики.

runtime - нет


непременно загляну..хотя ссылка не помешает
в программе не только логика присутствует


кому как. смотря какая логика, смотря какой сервер..в основном - да, но не всега

nerezus, 



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

В любом случае при серьезной работе с БД pconnect положение не спасет. Да за счет него PHP выиграет у cgi, но возможности тюнинга производительности доступные в Java или .NET, например, за счет настройки различных уровней кеша в php и cgi отсутствуют.  


Смотря что за логика.

нет, но в новой версии пхп будет connection pool



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

azesmcar, 


Тут все не так просто. И .NET и Java не буду компилится при каждом запросе к серверу. Они компилятся при первом обращении. .NET еще может и сохранить скомпиленную версию в системе. 

PHP активно развивается и это хорошо. Но пока он еще маленький. 





Насколько я знаю, memcached все же немного из другой области. И он требует программирования приложения с учетом его использования, я имел ввиду, что можно тюнить Java приложение не меняя код, просто меняя, например, настройки ORM фреймворка. 

неа.. Можешь юзать через свою обертку и тогда мемкеш всегда легко на другую кеш-систему заменить.

верно, но если не ошибаюсь он время от времени обновляет cash (могу ошибаться но помню что-то по этому поводу).
А вот насчет скорости - я сам тестировал, при первом запуске C# - C++ разница огромная, при втором - небольшая, но есть.
Java не тестировал, не писал на ней, и даже не знаю как она выглядет  просто видел тесты что джава уступает в производительности .NET

а по памяти?  

не понял вопроса

Wowa, 



я не знаком с memcached, и поэтому могу чего-то не понимать.  Но мне кажется, что мы с Вами говорим немного о разных вещах. 

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

Я же имею ввиду возможности настройки кэширования запросов к БД в таких ORM фреймворков, как Hibernate.

Hibernate полноноценного для ПХП конечно нет, но это не проблема. Т.к. даже в MVC все данные по запросу могла бы кешировать модель или Data Abstraction Layer (например в том же мемкеше).


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

на сколько больше памяти, в среднем, использовала программа написаная на c#, уверен что не 
, а раза в два, как минимум  

Lazin
а в этом смысле да!  

  

http://www.vitalik.com.ua/node/5
http://xodian.net/serendipity/index.php?/a...l-vs.-Ruby.html

perl как обычно обделили 

gcc, тест на увеличение переменной на +1 - это жесткий бред )

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

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

 Т.е. facebook, wikipedia и т.д. - это детские шалости?
хнык :'(

P.S. На каком основании ты говоришь такие несуразности? Масштабируемость - это не свойство ЯП.

Это сообщение отредактировал(а) nerezus - 11.6.2009, 13:23

возможно смотря как написать

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

если набрать в google.com 'drupal грузит хостинг' 'php nuke грузит хостинг' 'joomla грузит хостинг' 'ipb грузит хостинг' и т.д. то очень много кто жалуется
http://www.google.com.ua/search?hl=uk&...mp;aq=f&oq=

Добавлено через 10 минут и 3 секунды

да, мне подсказал так написать