LINUX.ORG.RU

PHP масштабируется не хуже Java


0

0

В этой статье рассматривается вопрос расширяемости веб сервисов построенных на PHP.

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

"Это просто не правда, что Java лучше скриптовых языков в плане расширяемости веб приложений. Я не буду делать далёко идущих выводов о том, что PHP лучше Java, потому что обычно не всё так просто."

>>> Статья

★★★★

Проверено: Shaman007 ()

Согласен, что дешевой, не согласен что быстрой для больших проектов и не согласен, что нечто большое и сложное на php будет работать быстрее или также как и на java.

lexius ★★
()

клевая штука палец. можно высасывать что хочешь. "Жаба приложения над которыми я работал обычно юзали оракелы и диби2. Я взял бесплатный MySQL и потому PHP rulez".

r ★★★★★
()

> разработка больших проектов на PHP является быстрой и дешевой.

а что насчёт поддержки? это зачастую важнее чем разработка

anonymous
()

Новость для того, чтобы устроить мортал комбат между "Жабофилами и быдлокодерами"?

:)

Valmont ★★★
()

Читал. долго думал. цифры не нашел.

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

Название PHP — (рекурсивная) аббревиатура, означающую «PHP: Hypertext Preprocessor» (ранее акроним расшифровывался как «Personal Home Page»). Изначально создавался в качестве надстройки над Perl для облегчения разработки веб-страниц.

PartyZan ★★★
()

Во, наконец-то прищучили жаб! PHP RULEZ.

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

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

Toxa
()

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

Дауж.

Достаточно взглянуть на это (уязвимости по ключевому слову php)
http://www.securitylab.ru/vulnerability/index.php?arrFilter_ff%5BSECTION_ID%5...
А потом на это уязвимости по ключевому слову java
http://www.securitylab.ru/vulnerability/index.php?arrFilter_ff%5BSECTION_ID%5...

Соотношение 1908/363

vada ★★★★★
()

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

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

>Новость для того, чтобы устроить мортал комбат между "Жабофилами и бдлокодерами"?

Или пхпфилами и быдлокодерами? за языком следи...

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

>Изначально создавался в качестве надстройки над Perl для облегчения разработки веб-страниц.

Разве? Помнится году в 2001 я краем глаза видел Embeded Perl - полностью покрывал возможности php по написанию "небольших гостевых книг"

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

> Помнится году в 2001

В 1994 году датский программист (ныне живущий в Канаде) Расмус Лердорф (Rasmus Lerdorf) написал набор скриптов на Perl для вывода и учёта посетителей его онлайн-резюме, обрабатывающий шаблоны HTML-документов. http://ru.wikipedia.org/wiki/Php

А ты говоришь 2001 Ж)

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

причем в основном эти якобы "Java" уязвимости относятся к JavaScript

anonymous
()

Java нужно мочить. Ruby намного удобнее, прозрачнее и навороченнее.

а главное - на порядок быстрее и свободнее.

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

А вы текст уязвимостей читали?

"SQL-инъекция в Shopweezle"

"Множественные уязвимости в apt-webshop-system"

"Множественные уязвимости в Cisco Optical Networking System 15000 Series"

"Уязвимость состояния операции в Microsoft Internet Explorer"

И при чём тут java и php? :)))

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

Кстати, про ruby: его можно поставить на shared хостинге (при наличии доступа к htaccess, cgi-bin)?

Как оно будет по роизводительности при таком подходе?

Davidov ★★★★
() автор топика

Приведите пример применения жавы, аналогичный по масштабам википедии. Там, напомню, юзается LAMP (с PHP в качесте P).

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

> Кстати, про ruby: его можно поставить на shared хостинге (при наличии доступа к htaccess, cgi-bin)?

> Как оно будет по роизводительности при таком подходе?

Как и обычно с cgi-bin, думаю :)

Но если юзаешь shared, то высокая скорость тебе не нужна, думаю.

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

>Как и обычно с cgi-bin, думаю :)

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

Там и так сервера тормозят в часы нагрузки :) Я боюсь, что если ещё и cgi сделать, то вообще смерть.

Davidov ★★★★
() автор топика

ИМХО

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

theserg ★★★
()

PHP - Pure Human's Puke

anonymous
()

>Next I was worried about database costs. The enterprise Java applications I had worked on were powered by expensive database software like Oracle, Informix, and DB2. I had decided early on to use MySQL for my database, which is of course free.

Фсьо, дальше ниасилил.

Пионерский бред.

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

>Приведите пример применения жавы, аналогичный по масштабам википедии. Там, напомню, юзается LAMP (с PHP в качесте P).

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

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

Замечу от себя, что подобный флейм - чушь собачья. Не бывает плохих языков программирования, бывают плохие программисты. Ас программирования и на бейсике вытворит такое, что средний кодер на Си хрен напишет.

anonymous
()

на джаве еще ни одной программы не видел кроме хелло вролод в консоле.

//гоблен.

anonymous
()

Бред.

Вы мне расскажите как у PHP с наработками? Как с серверами? Это раз. А еще расскажите мне где вы нашли теорию по которой ИНТЕРПРЕТАЦИЯ высокоуровнего языка быстрее интерпретации БАЙТКОДА? Не рассказывайте мне про компиляцию налету (она требует памяти и времени процессора). Как вы представляете себе реюзинг кода в терминах ресурсов компьютера, при использовании ИНТЕРПРЕТАЦИИ КОДА? И да, расскажите мне про отличия PHP 5.0 от java? И там и там мы видим (уже) понятие интерфейсов, объектов, наследования и т.д. И еще вы слышали про Hot Spot? Как у PHP с этим?

Да, жаба жрет немеренно памяти, да это недосмотр (а может вынужденный ход) санычей, но она НЕ МЕДЛЕННЕЕ. Она не сложнее. Она более развита и имеет за своей спиной БОЛЬШЕ монстров, которые ее двигают.

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

>если использовать пхп с умом то это будет на поряток быстрее жавы которая будет гонять гигабайты от субд на средний слой, чтоб быть независимой от субд. пхп + pl/sql займет

Пипец. Ты хоть сам понял что сказал? Это типа "язык высокого уровня потребует сложного компилятора, потому возьм ассемблер и все наваяем". Если не нужден миддлтаер или независимость то тебе блокировка сознания инопланетянами мешает писать точно так же?

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

> Я сильно сомневаюсь, что википедия отдает динамический контент. Скорее всего, там стоит прокся-акселератор, а коли так, то совершенно неважно, на чем работает бэкэнд -- 90% нагрузки все равно приходится на фронтэнд.

Угу. Кэширующие прокси на входе. Но я спрашивал про примеры :-) Пусть и с проксями.

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

Чувак, за языком следи. Чего нет в PHP, так это JITа. А вот как раз байт-код (только свой) есть у большинства современных скриптовых языков: у Питона, у PHP, у Перла... Про скорость работы Ruby промолчу.

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

>Приведите пример применения жавы, аналогичный по масштабам википедии

Забитая разной хренью база данных - это еще не масштаб. Сама википедия очень простая. К стати и кривая - я занимался интеграцией mediawiki с другим софтом - волосы начинают выпадать когда смотришь на шаманства с кешами внутри и пытаешься модифицировать данные мимо сайта.

ibm.com - вот там смотри на масштаб.

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

Да читал. :) Отфильтровывать впадлу было. Но тенденция на лицо.

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

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

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

>Скорее всего, там стоит прокся-акселератор, а коли так, то совершенно неважно, на чем работает бэкэнд -- 90% нагрузки все равно приходится на фронтэнд.

Почти прав. Контент статический. У него тупой файловый кеш внутри. Он все рендерит один раз и складывает на файловой системе. Даже в БД не ходит - только посмотреть на дату модификации страницы.

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

>чтоб программировать на java, нужно сначала обновить все копмьютеры: те, на которых идёт разработка, и боевые сервера - это дорого и сложно

Зато на этом держатся информационные системы масштаба предприятия, а не веб сервер с 2.5 страницами.

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

Следи за своим языком. Читай про Hot Spot. Потом будем говорить.

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

+ к тому:
$ host wikipedia.org
wikipedia.org has address 207.142.131.202
wikipedia.org has address 207.142.131.203
wikipedia.org has address 207.142.131.204
wikipedia.org has address 207.142.131.205
wikipedia.org has address 207.142.131.206
wikipedia.org has address 207.142.131.210
wikipedia.org has address 207.142.131.213
wikipedia.org has address 207.142.131.214
wikipedia.org has address 207.142.131.235
wikipedia.org has address 207.142.131.236
wikipedia.org has address 207.142.131.245
wikipedia.org has address 207.142.131.246
wikipedia.org has address 207.142.131.247
wikipedia.org has address 207.142.131.248
wikipedia.org mail is handled by 10 mail.wikimedia.org.
wikipedia.org mail is handled by 50 pascal.knams.wikimedia.org.

Deleted
()

> В этой статье рассматривается вопрос расширяемости веб сервисов построенных на PHP. > Автор приходит к выводу, что разработка больших проектов на PHP является быстрой и дешевой.

Угу, оч быстрая и дешевая, но вот потом...

Однажды админ написал страничку по учете (точнее -- визуализации всей энтой хрени из БД в хтмл-виде) траффика юзверями, на ПХП (соко это заняло времени не знаю не спрашивал)... Но время идет, все меняется... Появился новый дистриб, админ его поставил... Вирсия ПХП там отличалась в н-ном знаке субверсии... Естественно, его страничка не заработала. Он день убил в попытках все это реанимировать, а на следующий день до конца обеднего перерыва он (хоть и не без сторонней помощи в моем лице) переделал все это на перл. После этого случая перл выдержал несколько обновлений и страничка работать не перестала. Занавес.

Эта история оч хорошо отражает масштабитуемость и быстроту разработки веб сервисов на ПХП...

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

> если использовать пхп с умом то это будет...
силлогизм, ибо ум и использование пхп несовместимы принципиально.

anonymous
()

Ну вообще....

Слышали о HP OpenView SD? Мощная система! А на чем написана? Нет. Пыхпыхом на и не пахнет. Java + perl. Быдлокодеры сосут леденцы...

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

>PHP - Personal Home Page

вас обманули

PHP - PHP: Hypertext Preprocessor

"Personal Home Page Tools" = PHP/FI (набор скриптов на Perl и C, которые общего с РНР имеют тока название ;)

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