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

>Понятно. Как только был задан конкретный вопрос, тема слилась. Уважаемый Шетухин Андрей Владимирович!

Спешу Вас уверить, что в конексте данного обсуждения (вопрос применимости языков программирования к написанию динамического веб контента) данный вопрос является не существенным, а попросту говоря, нехер тут гнать! Числодробилки это НЕ ПХП, а Java это НЕ ВЕБ! Надеюсь за этим считать дискуссию закоченнной. С ув. ГОБЛЕН.

Во первая часть быдлокодера (слово "быдло") вылезла наружу...

ЗЗЫ Можно обращаться как $a['1'], всё будет пучком, и не надо говорить что язык не должен позволять так делать, это программист не должен так делать, бардак он в головах.

Идём и смотрим http://forge.novell.com/, целый sorceforge, прицем движок у них переписаный, они его дают скачать.

>На IBMе вагон и маленькая тележка разных сервисов (alfaworks, developerworks, etc)

А нельзяли хоть немного поподробнее описать парочку, для чего и кто использует и т.д.?

Как уже написал идём на forge.novell.com и смотрим кого они благодарят.

>MHO масштабируемость PHP - это миф. >вы видели trasparent fall talerants на PHP? >Да хотя бы приличный clustering или cache management приличный? >Что там... >Много вы знаете PHP программистов умеющих использовать debugger? >А для того что бы создавать большие решения вам нужен не только >debugger. Вам нужна полноценная IDE с поддержкой Refactoring/Remote >Debugging/UML Modeling etc. На php вообще хоть раз программили? Идём на zend.com и скачиваем Zend Development Environment (+ ZendServer), я использую 3.2, а сейчас уже 5. Правда она платная, но можно и купить, причём цены доступные.

>Производительность – у производительность PHP никакая. >Если есть ещё люди которые говорят - Java медленная, что же они говорят >про PHP? ;-) Для сайтов/порталов её, как ни странно хватает, если код написан грамотно.

>Му-ха-ха. На действительно корпоративных сайтах его не было разве что по недоразумению. Ты не путай "корпоративный сайт" с десятком страниц на котороых три текста про нашу корпорациию и форма для фидбека.

Расскажи это на том же forge.novell.com и novell.com.

Сразу и всем кто тут говирмт что мол PHP сливает Java по производительности, а оно надо на сайте? Или у нас web должен уметь обсчитывать кластерные задачи? А в результате всё сводится к тому, что в большинстве случаев проще и дешевле взять номальных программеров и написать всё на php.

> Подрастёте до энтерпрайза - поймёте, а пока штампуйте хоум-пейджи на своём PHP.

Уважаемый подросток, подросший до энтерпрайза, откройте глазки. Фирм,
размера IBM можно сосчитать по пальцам. Средний и мелкий энтерпрайз
давно освоил php.

> А PHP-скрипты самые устойчивые)))

Ребеночек, устойчивы не скрипты, а библиотеки.

> Взгляните на Oracle Applications(OeBS) из коммерческих продуктов.

И чо? В главном продукте Оracle знаешь как часто и насколько серьезные
дырки находят? Если знаешь, то зачем свистишь?

> Но Вы же супер-мега-кодер и запросто сбацаете ERP-систему на PHP.

А то. Я понял бы, если бы ERP-систем на PHP не было. А так - очередной
пук в воду.

Какой процент знакомых тебе PHP программистов используют refactoring/remote debuging etc? ;-)

re: Для сайтов/порталов её, как ни странно хватает, если код написан грамотно.
Порталов я на php больших почти не видел, разве что вечно мертвый sourceforge. Ниская производительность иногда приемлема, - все зависит от проекта, я знаю проекты которые отказывались от С++ в пользу С из за вопросов производительности. Знаю проекты которые приходилось переписывать с PHP на Java по тем же причинам. В обратную сторону примеров не знаю.
re:Вам нужна полноценная IDE с поддержкой Refactoring/Remote >Debugging/UML Modeling etc. На php вообще хоть раз программили? Идём на zend.com и скачиваем Zend Development Environment (+ ZendServer), я использую 3.2, а сейчас уже 5. Правда она платная, но можно и купить, причём цены доступные.

А почему бы не phpeclipse?
Давайте вернемся к теме разговора – некто утрверждал что php масштабируется не хуже java.

Я спрашиваю – каким образом проверяли? Статья – сплошная вода.


Frameworks/Specs&impls позволяющие создавать масштабируемы решения (читать кластеризация, прозрачна отказаустойчивость и т.д.)- PHP проигрывает.
Безопасность - PHP проигрывает.
Скорость – PHP проигрывает.
Стоимость поддержки - PHP проигрывает.
Стоимость разработки - PHP проигрывает (это к вопросу о качественных IDE).
Стоимость хостинга – на маленьких проектах выигрывает PHP на больших - одинаково.

> Насчёт того, что PHP занял свою нишу и Java туда не пробраться - согласен. Просто Java это и не надо

Ну, как же, как же? А кто тогда тут с пеной у рта рассказывает, что
php - недоязычок и т д.? А кто каждый раз тычет пальцем в ibm.com,
и говорит, вот каким должен быть веб ;)))

> PHP проигрывает.
> Безопасность - PHP проигрывает.
> Скорость – PHP проигрывает.
> Стоимость поддержки - PHP проигрывает.

Хм, а сам говорит, что статья - сплошная вода. А вышеприведенные
высказывания - это что? Бензин? ;)

самое смешное, что главными продвигателями пхп являются oracle и ibm у этому недоязыку посвещены целые разделы, где подробно разъеснено почему пхп scale

Action.

> Сразу и всем кто тут говирмт что мол PHP сливает Java по производительности, а оно надо на сайте?

Да ни хрена он не сливает! Проверено. И статью прочитайте наконец. В ней
знающие люди отвечают - самое тормозное место любой системы - БД.

> самое смешное, что главными продвигателями пхп являются oracle и ibm

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

>Какой процент знакомых тебе PHP программистов используют refactoring/remote debuging etc? ;-)

А мы его и используем =)

>А почему бы не phpeclipse?

Можео и её, но, есть к примеру visual studio .net, юзают почему то её, а не скачивают vc++ toolkit и .net framework + Eclipse. То же и тут. А phpeclipce уже умеет дебаг? Типа как в визуалке F5 и поехал? Или remote debug?

>Давайте вернемся к теме разговора – некто утрверждал что php масштабируется не хуже java.

Я такого не утверждал, я только против того что сразу начинается а у нас таааакооой велечины (это про java), а ваш пхп только для домашних страничек, потому как нам IBM и SUN скзали что для больших контор только JAVA! ИМХО Java в веб среде, в смысле большие порталы, нужна на мой взгляд только для увязывания этого мега-портала(корп. сайта) только с уже сущ. инфраструктурой на JAVA или же для боооольших нагрузок (или вообще что нибудь специфческое). И то что такие порталы есть, не говорит о том что PHP масштабируется хуже чем JAVA.

>Frameworks/Specs&impls позволяющие создавать масштабируемы решения (читать кластеризация, прозрачна отказаустойчивость и т.д.)- PHP проигрывает.

Тут не php проигрывает, а mysql который используют в большей части проектов для БД. Как надо будет так и появится под php, если уже не появилось, под Java это тоже не сразу родилось.

>Безопасность - PHP проигрывает.

И чем же она проигрывает?! Тем что под php программят недоучки? Так и аод java таких найдётся туча.

>Скорость – PHP проигрывает. Да? На мат. вычислениях, что то я больше тестов не видел.

>Стоимость поддержки - PHP проигрывает. >Стоимость разработки - PHP проигрывает (это к вопросу о качественных IDE).

Да?! И чем же? IDE от zend есть, не хуже сановской или от MS. Стоимость? Так все кажется убеждены что php дешевле. Всё зависит от программистов, так же как и с java, грамотный код IDE за тебя не напишет. То же и с воддержкой. Вообще эти два утверждения высосаны из пальца, так же как про безопастность.

>Стоимость хостинга – на маленьких проектах выигрывает PHP на больших - одинаково.

Свой сервер, а там рули как хочешь.

>Идём и смотрим http://forge.novell.com/, целый sorceforge, прицем движок у них переписаный, они его дают скачать.

С ума сойти. collab.net на котором запущен java.net, sunsource.net и tigris.org

Но вся фишка в том что это yet another system рядом с новеловским сайтом. Как лежащий рядом project mono который лежит на mediawiki или лежащий рядом opensuse -> на другом mediawiki. Я про то и говорю - они дети по сравнению с корпоративным порталом IBM где все одна интегрированная система с тучей сервисов. Или sun.com. Где мой аккаунт канает ВЕЗДЕ начиная от галимой качалки каких нибудь поделок с альфаворкса, редбуков или сорцов java у сантехников и заканчивая закрытой Sun Partner Program или заказа сидюков с IBM.

> Самое смешное, что те, кто все это придумал, уже давно сами охладели

И давно это Эккель и ТЕйт стали "теми кто это придумал"? Они даже не программисты - они писатели. И продаватели консалтинга.

К стати с чего вы взяли что yahoo.com работает на PHP? Насколько видно из нета на PHP там написали несколько новых сервисов. И все....

>К стати с чего вы взяли что yahoo.com работает на PHP? Насколько видно из нета на PHP там написали несколько новых сервисов. И все....

??? Это я когда то такое сказал?

ЗЫ А по поводу всех этих крупных систем перечисленных выше, так можно всё спихнуть на пиар JAVA и на то что ещё совсем недавно (относительно), php "ходил пешком под стол". Тот же .net не сразу родился, я его pre pre pre beta ещё в 2000 году юзал, а щас ничего, есть и у него место под солнцем.

>К стати с чего вы взяли что yahoo.com работает на PHP? Насколько видно из нета на PHP там написали несколько новых сервисов. И все....

да, выкинули свой y! скрипт и новые сервисы делают на пхп
http://developers.slashdot.org/article.pl?sid=02/10/29/2052239

>Спешу Вас уверить, что в конексте данного обсуждения (вопрос
>применимости языков программирования к написанию динамического веб контента)
>данный вопрос является не существенным, а попросту говоря, нехер тут гнать! 

Еще как существенным. Особенно при высокой посещаемости ресурса.
Потому, что одно - это прямой достум по смещению в памяти,
и совершенно другое - посредством hashmap или тем более rb/b-tree.
А все это вместе - разное ВРЕМЯ ответа.

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

>Числодробилки это НЕ ПХП,

Значит, те же биллинговые системы и вебморды к ним - это не PHP.
О каких Enterprise-решениях мы будем говорить?

>а Java это НЕ ВЕБ!

Не Enterprise-сайты - это не Java. А вовсе не весь web.

>ЗЗЫ Можно обращаться как $a['1'], всё будет пучком,

Еще раз: Я ОБРАЩАЮСЬ ТАК: $a[$b].
И ЗАРАНЕЕ НИЧЕГО СКАЗАТЬ ПРО СКОРОСТЬ ДОСТУПА НЕЛЬЗЯ.

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

Нет. Это именно язык не должен позволять так делать.
Потому, что если что-то сделать НЕЛЬЗЯ В ПРИНЦИПЕ, это сделано НЕ БУДЕТ.
А если МОЖНО - то будет сделано ОБЯЗЯТЕЛЬНО. Если не по умыслу, то по недосмотру.

>есть и у него место под солнцем.

О том и разговор. Вот там и сидит. А не писать дурацкие статить на тему мы "мы отказались от окакла в пользу mysql чтоб сэкономить и потому php scales good".

>http://developers.slashdot.org/article.pl?sid=02/10/29/2052239

Это я читал (не на /. но это интерьвю). А еще одну ссылку? А то из нета выходит что один единственный базар в котором какой-то engeneer из яхи на выстовке говорит что они рассматривают возжность двинуть в OSS и попробуют с PHP (да еще в 2002 году). С тех пор мертвая тишина на тему? Яхушные сервера не распазнаются как apache. Повторяю вопрос - с чего вы взяли что yahoo.com на php?

> Еще как существенным. Особенно при высокой посещаемости ресурса.

Опять теоретический бред. Читаем статью ещё раз и всасываем истину.
Главный фактор, влияющий на скорость приложения - скорость работы БД.
Независимо от ЯП. Пишем на лбу и часто смотримся в зеркало ;)

Почему-то отдельные недалекие личности считают, что php - тормоз, ибо
php-приложение на одноголовом x86 сервачке c гигом памяти работало
значительно медленнее, чем пришедшее ему на смену жаба-приложение,
поставленное на 10-ти 8-ми процовых серваках с террабайтом памяти суммарно ;)))

Вы думаете, я утрирую? Именно так чаще всего и происходит! Крутые парни
заказывают переписать софт с php на жабу. Им естесно сразу предъявляют
параметры по железу ;) Ну, те, конечно, сопят носом, но отступать-то некуда ;) Потом рассказывают сказки о том, как оно БЫЛО, и как СТАЛО ;)

> Значит, те же биллинговые системы и вебморды к ним - это не PHP.
О каких Enterprise-решениях мы будем говорить?

А где биллинговая система считает веб-мордой? ;)

>Я утверждаю всего лишь, что ПХП плохо подходит для серьезных
>(высокопосещаемых/сложных по бизнес-логике/крупных) проектов.

в тетий раз спрашиваю, чем php+pl/sql будет несерьозней чем jsp+java ? java будет на порядок тормозней, например oracle iAs не шевелится без oracle cache вообще.

>Повторяю вопрос - с чего вы взяли что yahoo.com на php? c того что официальные лица yahoo присутствуют на zendовских конференциях и регулярно рассказывает как зашибись у них _работает_ пхп, и что пхп их стратегический выбор. да и между прочим оракл, официально супортит пхп в своем iAs и zend core for oracle. Action.

>Еще как существенным. Особенно при высокой посещаемости ресурса. Потому, что одно - это прямой достум по смещению в памяти, и совершенно другое - посредством hashmap или тем более rb/b-tree. А все это вместе - разное ВРЕМЯ ответа.

Большинство ресурсов в вебе делают расчёт числа пи для каждого посетителя? Или им надо отдать сгенереную страничку с данными с диска или БД?

>Я не утверждаю, что на ПХП нельзя писать. Можно, раз пишут. Я утверждаю всего лишь, что ПХП плохо подходит для серьезных (высокопосещаемых/сложных по бизнес-логике/крупных) проектов.

Что зханчит серьёзных? Тем что их много посещают, и там есть бизнес логика? Или php не поспеет за генерацией отчётов? Тот же ibm.com даааалеко не самый быстрый веб ресурс. И большая часть нагрузок на серваки ibm скорее из-за того что с них что-то качают.

>Значит, те же биллинговые системы и вебморды к ним - это не PHP. О каких Enterprise-решениях мы будем говорить?

А что все биллинговые системы это уже java? Или может это связка c/c++(ещё что нибудь) + что-то.

>Не Enterprise-сайты - это не Java. А вовсе не весь web. А понятие масштабирования применимо только к Enterprise-сайтам?

>ет. Это именно язык не должен позволять так делать. Потому, что если что-то сделать НЕЛЬЗЯ В ПРИНЦИПЕ, это сделано НЕ БУДЕТ. А если МОЖНО - то будет сделано ОБЯЗЯТЕЛЬНО. Если не по умыслу, то по недосмотру.

Точно, надо выкинуть c/c++ на свалку, потому что там можно создавать указатели в произвольное место а потом к ним обращаться. Кстати выше в теме был пример с JAVA про Integer и Short кажется.

> А phpeclipce уже умеет дебаг? Да.

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

Я не говорил, что только для домашних, я говорил что IMHO php лучше использовать для дешевого web hosting'a, во всех остальных случаях я не вижу его приемушеств (буду благодарен если кто-то объяснит).

re:ИМХО Java в веб среде, в смысле большие порталы, нужна на мой взгляд только для увязывания этого мега-портала(корп. сайта) только с уже сущ. инфраструктурой на JAVA или же для боооольших нагрузок (или вообще что нибудь специфческое).

Не могу согласится, IMHO для java написано очень много _качественных_ библиотек и фреймворков существенно упрощающих разработку. Это и ORM - TopLink,Hibernate,JDO,EJB3 Web фреймворки - JSF,Struts,Spring MVC Кластеризация - Tomcat кластеризуется на раз, насколько легко кластеризовать Apache + PHP, если умеете это делать, поделитесь знаниями со мной и разработчиками sf.net? Так почему же тогда не использовать java на проектах масштабом по меньше? Какие плюсы есть у PHP или в чем оно хотя бы просто не хуже?

>И то что такие порталы есть, не говорит о том что PHP масштабируется хуже чем JAVA.

Что вы называете масштабированием? И в чем по вашему PHP не уступает?

Пришла в голову еще пара моментов.

6. Потоки, время жизни которых не стремится к нулю. Как можно серьезно работать с языком, в котором простейший юс-кейс - работа некоего процесса в фоне - выполняется путем многочисленных приседаний с кроном и лок-файлами? При этом процесс, как выше замечено, не может иметь доступ к бизнес-объектам, а должен подгружать себе их КОПИИ? Как ему, например, узнать, что объект был изменен другим тредом?

7. Наведенная проблема - статические разделяемые данные. В ПХП типичнейший код entry point'а - достать из сессии user id и вытащить этого юзера из базы, затем вытащить из другой таблицы его права и наконец сравнить права с запрашиваемым УРЛом. Нет, конечно, процессорные циклы нынче дешевы - но как-то в нормальных системах на то есть статические пулы.

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

> Это и ORM - TopLink,Hibernate,JDO,EJB3

Есть подобные вещи и для php. Ноль преимуществ.

> Web фреймворки - JSF,Struts,Spring MVC

Отстой полнейший. Вы с ними работали? Стоимость разработки такими с позволения сказать фрэймворками минимум вдвое выше, чем на php с набором
необходимых библиотек.

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

О, с этого надо было начинать. Хоть одна здравая причина использования
жабы в вебе.

> или же для боооольших нагрузок

Это ложь.

> (или вообще что нибудь специфческое).

Это возможно.

> Как ему, например, узнать, что объект был изменен другим тредом?

Басню Крылова "Обезьяна и очки" читал? Почитай. Ответ на твой вопрос.

> Нет, конечно, процессорные циклы нынче дешевы - но как-то в нормальных системах на то есть статические пулы.

А трудно представить, что между базой и запросом можно поставить кэш?

> работа некоего процесса в фоне - выполняется путем многочисленных приседаний с кроном и лок-файлами?

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

На вебе PHP выигрывает у жабы по _всем_ параметрам - и по стоимости
разработки, и по времени разработки, и по стоимости обслуживания, и по
стоимости владения, и по скорости, и по масшитабируемости. Если видите,
что на вебе используют жабу - это либо очень богатая контора, сорящая
деньгами а-ля ibm, либо глюпый, но типа крутой студент а-ля аффтар LOR ;)

2southern_sun (*) (12.04.2006 19:52:35):

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

Да, да, а если не существенно, то зачем поднимать тему? Тем более,
что не раз уже обсосано про APC PHP accelerator и MCache. Если уж
так волнует производительность, почему не потрудиться прочитать
о средствах её поднятия?


> Отсутствие внятной системы пакетов опять-таки приводит к значительным рантайм-задержкам просто на постоянное открытие/чтение файлов. Более-менее архитектурно серьезная система при обработке отдельного HTTP запроса может потребовать подгрузки сотни файлов.

Решаемо. Смотри ответ выше.

> Я не говорю о домашних страницах и гордо так называемых "порталах"
с 3-4 сущностями (юзер, пост, коммент).

А чего так бедно с воображением? Стремление умышленно принизить
кого-то говорит о наличии комплекса неполноценности.

> 4. В ПХП нет средств для построения систем с развитой модельной структурой. В частности, в нем нет ORM уровня Hibernate.

Уровня Hibernate может и нет, но есть ведь propel, ez_pdo, DB_DataObject. Их вполне достаточно в большинстве случаев.

> Система _должна_ иметь средство для хранения полноценных бизнес-объектов (beans); а бизнес-объекты должны быть именно объектами, а не КОПИЯМИ друг друга на каждый HTTP-запрос.

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

>Пришла в голову еще пара моментов.
глупости у вас в голове, гоните их

>6. Потоки, время жизни которых не стремится к нулю. Как можно серьезно работать с языком, в котором простейший юс-кейс - работа некоего процесса в фоне - выполняется путем многочисленных приседаний с кроном и лок-файлами? При этом процесс, как выше замечено, не может иметь доступ к бизнес-объектам, а должен подгружать себе их КОПИИ? Как ему, например, узнать, что объект был изменен другим тредом?
---
это делается на уровне бизнес логики. а не представления. и делается тривиальным dbms_job, причем гораздо гибче чем может java. нука расскажите как запустить процесс который бы запускался именно через 5 минут после запуска предыдущего запуска (т.е. зависил от нагрузки)? т.е. если у меня процесс проработал 7 минут, не получилась так что еще не закончился первый процесс а уже запустился следующий ?

>7. Наведенная проблема - статические разделяемые данные. В ПХП типичнейший код entry point'а - достать из сессии user id и вытащить этого юзера из базы, затем вытащить из другой таблицы его права и наконец сравнить права с запрашиваемым УРЛом. Нет, конечно, процессорные циклы нынче дешевы - но как-то в нормальных системах на то есть статические пулы.
---
опять глупость и недоразвитость java, права тривиально проверяет субд, мало того оракл может делать это с row level security или вообще c помощью label security, в java есть хотябы намеки на такие технологии чтоб работало с любой субд ?

Action.

>Что вы называете масштабированием? И в чем по вашему PHP не уступает?

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

http://phplens.com/phpeverywhere/node/view/15

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

А вообще хороший был пример с поиском, где ключем фигурирует int и поиском где ключ - строка. Хотя конечно может быть это и не критично для приложения которое занимается только тем что делает select * from table, insert values into table. Тут понятно узким местом будет транспорт между базой и приложением, а то и сама база.

Вообще имхо у PHP есть очень большой плюс - возможность быстро реализовать то, что нужно прямо сейчас. Так чтобы это как-то работало. С тем же jws чтобы создать минимальный осмысленный кусок кода нужно проделать куда больше телодвижений.

PHP имеет смысл как способ сделать, чтобы завтра уже был прототип, а значит и шанс того что проект будет жить в принципе. У java в этом плане все гораздо труднее.

>либо глюпый, но типа крутой студент а-ля аффтар LOR ;)

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

Я молчу про Perl, forum.ixbt.com в дневное время было невозможно пользоваться поиском, его отключали админы, из-за того, что процы не тянули нагрузку одновременно по генерации страниц и поиску. Поиском жертвовали. На PHP было бы то же самое, т.к. все процессорное время бы уходило на постоянную интерпретацию скриптов. Ну и нафига тогда "скорость" и легкость PHP? Если жабий код один раз компилируется и постоянно висит в памяти, да еще и HotSpot оптимизируется? И не грузится на каждый httpзапрос в память заново?

>чем пришедшее ему на смену жаба-приложение, поставленное на 10-ти 8-ми процовых серваках с террабайтом памяти суммарно ;)))

>Вы думаете, я утрирую? Именно так чаще всего и происходит! Крутые парни заказывают переписать софт с php на жабу. Им естесно сразу предъявляют параметры по железу ;) Ну, те, конечно, сопят носом, но отступать-то некуда ;) Потом рассказывают сказки о том, как оно БЫЛО, и как СТАЛО ;)

Ты издеваешься или правда не понимаешь ничего? Ну посмотри же сюда http://www.linux.org.ru/server.jsp какие 10 8-ми процовых серваков?

>Ты часто видел, как LOR дефейсили? Часто видел "ошибка записи в базу, база недоступна" Я на PHP-порталах вижу эту байду постоянно. LOR летает, PHP форумы-порталы рожают страницу по полминуты.
--

да в прошлом году lor каждый месяц был часами дауне или с null point exeption, а летать лор стал только после того как деньги на железо выклянчили, до этого еле шевелился. и посиск к стате, поиск до сих пор свой сделать немогут, конечно с поиском сразу просядет.

>На PHP было бы то же самое, т.к. все процессорное время бы уходило на постоянную интерпретацию скриптов.

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

Action.

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

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

>>Ты часто видел, как LOR дефейсили? Часто видел "ошибка записи в базу, база недоступна" Я на PHP-порталах вижу эту байду постоянно. LOR летает, PHP форумы-порталы рожают страницу по полминуты.

>>Я молчу про Perl, forum.ixbt.com в дневное время было невозможно пользоваться поиском, его отключали админы, из-за того, что процы не тянули нагрузку одновременно по генерации страниц и поиску. Поиском жертвовали.

лол/бугага/я рыдалъ, сравнили посещаемость лора и иксбит :-)) Аффтар, ты риальна зажег, риспект :-)

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

Будем и на том и на этом писать какая кому разница время серавно свистунов вытрет. DB2 + JAVA логика + TOMCAT отображение = 63мс на 138 клиентов и на 16 связвнных таблиц в основной 143 колонки и около 900000 строк.

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

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

> Ты часто видел, как LOR дефейсили? Часто видел "ошибка записи в базу, база недоступна"

Про дефейс сведений не имею (может и было, да быстро исправлено), про
ошибки - регулярно вижу тормоза, регулярно вижу простыню с описью "java
exception bla-bla".

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

Опа. Здесь остановимся. Ибо сравнение теплого с мягким. У вас вообще
все перемешалось - тут и perl, тут и LOR с тремя тысячами хитов в день,
и ixbt, где столько же хитов, но только в минуту ;)

> Если жабий код один раз компилируется и постоянно висит в памяти, да еще и HotSpot оптимизируется?

На каком железе, брателло? Ты на этом же железе дай php побегать, а
потом приди, расскажи нам незнающим, как оно в сравнении с жабой ;)

> Ты издеваешься или правда не понимаешь ничего? Ну посмотри же сюда http://www.linux.org.ru/server.jsp какие 10 8-ми процовых серваков?

Это ты конкретно издеваешься ;) А хотя... знаешь, LOR'у с его тормозами
вовсе не помешал бы такой сервачок. Хотя бы один. Правда, его коллега -
сайт linux.ru.net с его php-движком на моей памяти долгое время работал
на пне 166 Mhz и 64Mb памяти. Тормозов, как на LOR'е не было близко даже.

> DB2 + JAVA логика + TOMCAT отображение = 63мс на 138 клиентов и на 16 связвнных таблиц в основной 143 колонки

Слабовато, ну да ладно, типа зачот ;) Только железки забыл описать.