Выполнение PHP-приложений в Apache Geronimo

День ПХП на ЛОРе?

>Выполнение PHP-приложений в Apache Geronimo

Читаю заголовок как security новость: "удаленное выполнение PHP-приложений в Apache Geronimo". Аж екнуло...

Эта штука работает именно как мост, т.е позволяет использовать общие сессионные переменные. Но есть еще один гораздо более интересный проект, в котором нет никаких мостов, а роль интерпретатора PHP исполняет Java Servlet (http://www.caucho.com/resin-3.1/doc/quercus.xtp) И вот там то и начинается самое интересное, например вызов Java-кода из PHP. Аналогией являются Jython и JRuby

А зачем это вообще? Типа легкий способ перелезть с PHP на JavaEE - писать на PHP под JavaEE ? :)

С совместимостью у него тоже неплохо: The growing list of PHP software certified running on Quercus includes DokuWiki, Drupal, Gallery2, Joomla, Mambo, Mantis, MediaWiki, Phorum, phpBB, phpMyAdmin, PHP-Nuke, Wordpress, and XOOPS.

>>А зачем это вообще? Типа легкий способ перелезть с PHP на JavaEE - >>писать на PHP под JavaEE ? :) Навскидку: 1) Сопровождение. Нет нужды настраивать чуждую джавистам среду в виде PHP, если хочется попользовать какую-то программу на PHP 2) Интеграция разнородных систем. 3) Улучшение масштабируемости путем запуска на кластере J2EE серверов.

Сами авторы говорят: Quercus is much more than just yet another PHP engine. Quercus is the first to tightly integrate the web server with a PHP engine. Quercus runs on top of Caucho Technology's Resin Application Server. As a result, PHP applications can automatically and immediately take advantage of Resin's advanced features like connection pooling, distributed sessions, load balancing, and proxy caching.

Что интересно, по их словам PHP code is interpreted/compiled into Java

> Навскидку: 1) Сопровождение. Нет нужды настраивать чуждую джавистам среду в виде PHP, если хочется попользовать какую-то программу на PHP 2) Интеграция разнородных систем. 3) Улучшение масштабируемости путем запуска на кластере J2EE серверов.

Хм... спорные аргументы: 1. Сопровождение чего и где проще-то становится? Обычно Apache (или кто еще) все равно есть вместе JavaEE Web-container на площадках. 2. Интеграция разнородных систем делают обычно через регламентацию открытых и малоизменяемых протоколов (через одни и теже переменные в сессиях это какой-то "новый" путь). 3. А что для PHP нет родного способа как-нибудь без Java это делать? 8-)

>Что интересно, по их словам PHP code is interpreted/compiled into Java

Ну да - а зачем велосипед изобретать.

>>Что интересно, по их словам PHP code is interpreted/compiled into Java

>Ну да - а зачем велосипед изобретать.

Было бы забавно если прямо в байт-код :) Правда тут потрудиться пришлось бы больше.

>Было бы забавно если прямо в байт-код :) Правда тут потрудиться пришлось бы больше.
Я уверен, что компилируется в Java байт код. Вы это же имели ввиду?

>Я уверен, что компилируется в Java байт код. Вы это же имели ввиду?

В смысле они в байт-код и сделали? Я не смотрел, но по приведенной цитате "PHP code is interpreted/compiled into Java" не совсем ясно, во что преобразуется. Но я, с учетом трудозатрат, понял что делается сначала Java-код, а потом байт-код, как это происходит с JSP.

> Но есть еще один гораздо более интересный проект, в котором нет никаких мостов, а роль интерпретатора PHP исполняет Java Servlet (http://www.caucho.com/resin-3.1/doc/quercus.xtp) И вот там то и начинается самое интересное, например вызов Java-кода из PHP. Аналогией являются Jython и JRuby

Э, уважаемый... ничего не напоминает?? По мне - так чистый .Net во плоти.

А если учесть "Что интересно, по их словам PHP code is interpreted/compiled into Java" дык вообще полный вендекапец какой-то.

О! А инструкция-то на русском!

>О! А инструкция-то на русском!

К вендекапцу?

"PHP Java Bridge был разработан для компенсации отсутствия поддержки PHP в среде Java. Эта новая разработка привела также к появлению поддержки PHP в J2EE-серверах, в том числе Geronimo. Таким образом, Bridge обеспечивает полную PHP-функциональность в Geronimo через CGI-интерфейс PHP, где в настоящее время поддерживается все, начиная с базового синтаксиса PHP и заканчивая переменными сессии."

В общем самому проще написать севрлет и из него тогкать php как cgi, если сильно надо.

>>Хм... спорные аргументы:
Конечно спорные. Мы же не про сферического коня в вакууме говорим, с которым все просто и понятно :) Дьявол он в деталях кроется, в мелочах.

>>1. Сопровождение чего и где проще-то становится? Обычно Apache (или кто еще) все равно есть вместе JavaEE Web-container на площадках.

Я не рассматривал это с точки зрения хостинга, например. Речь скорее идет о внутренних серверах компании, на которых крутятся собственные приложения. У меня вот на сервере PHP не стоит, а стоят Apache (балансировка нагрузки через mod_jk)+JBoss. Да, PHP я туда безусловно поставить могу. Но вот ставить его новые версии, хотя бы для устранения найденных уязвимостей, все-же дополнительный труд. А я его не люблю :) Но да - в том движке PHP на сервлетах тоже могут быть уязвимости, ага - мир не идеален.
>>2. Интеграция разнородных систем делают обычно через регламентацию открытых и малоизменяемых протоколов (через одни и теже переменные в сессиях это какой-то "новый" путь).
Да по разному бывает. Мне вот нужно было пару раз оценивать проекты, в которых нужна была интеграция между нашей системой, написанной на J2EE, и системой заказчика (ASP или PHP) В частности, требовалась бесшовная интеграция в части аутентификации. Навроде SingleSignOn. И модифицировать _свой_ код они не всегда могли. А тут уже приходилось выкручиваться разными способами, в том числе и через общие сессии.
Которые можно сделать многими способами (например через общую БД, файловую систему, etc

>>3. А что для PHP нет родного способа как-нибудь без Java это делать? 8-)

Наверное есть :). И кластеризация, и много чего еще можно сделать, если люди творческие и не косные, хотят и могут учится новому. И сделать в конечном итоге. Но времени займет больше. И будет стоить соответственно дороже.
С моей точки зрения диапазон готовых, обкатанных решений для кластеризации для J2EE больше.
Возьмем например JBoss. Для того, чтобы поднять на нем полноценный кластер с поддержкой кластеризации HTTP-сессий, мне лично понадобится примерно 10-15 минут.
1) Установить JDK
2) Скачать и распаковать JBoss
3) Запустить JBoss/bin/run.bat -c all (под linux все аналогично)
Все. In-Memory кластеризация для HTTP сессий там работает из коробки. Причем в последней версии масштабируемость очень сильно увеличена за счет применения т.н BuddyReplication, когда репликация ведется не между всеми серверами в группе, а между парами. Раньше такое было только в очень дорогих серверах типа WebLogic.
И замечу, чтобы подключить новую машину в кластер, нужно просто проделать ту-же процедуру на другом сервере. И ноды друг-друга найдут в автоматическом режиме.

Резюмирую: PHP хороший язык. Благодаря ему в том числе создана критическая масса программистов и, в конечном итоге, решений, заточенных под веб.
И то, что можно вот-так вот интегрировать PHP с J2EE очень здорово. Много полезного софта написано на PHP, зачем же отказывать себе в удовольствии его использовать.

>>Э, уважаемый... ничего не напоминает?? По мне - так чистый .Net во плоти. Ну и замечательно. Как по мне, иметь возможность прототипирования на Ruby с использованием готовых компонент, написанных на Java, в ряде случаев может ускорить разработку.

>>А если учесть "Что интересно, по их словам PHP code is interpreted/compiled into Java" дык вообще полный вендекапец какой-то. compiled into Java->JIT->native code->увеличение скорости. И это тоже здорово.

>Резюмирую: PHP хороший язык. Благодаря ему в том числе создана критическая масса программистов и, в конечном итоге, решений, заточенных под веб. И то, что можно вот-так вот интегрировать PHP с J2EE очень здорово. Много полезного софта написано на PHP, зачем же отказывать себе в удовольствии его использовать.

Про JavaEE и кластеризацию понятно - сами с усами :-) Откровенно говоря впервый раз встречаю Java-разработчика, который хочет с PHP иметь дело. Джей-питонистов и рубистов встречал :-)

>>Про JavaEE и кластеризацию понятно - сами с усами :-) Откровенно говоря впервый раз встречаю Java-разработчика, который хочет с PHP иметь дело. Джей-питонистов и рубистов встречал :-)

Я прагматик :) Что удобнее, то и использую :)

а объясните что такое кластер применительно к пхп ? там положил сесию на nfs или в бд ... вот тебе и кластер ...

Minotaurus.

>а объясните что такое кластер применительно к пхп ? там положил сесию на nfs или в бд ... вот тебе и кластер ...

Да, такой вариант кластеризации возможен.
И делают его в случае, когда приложение на PHP реализует стратегию Sharing-Nothing, т.е кроме сессионных переменных общих разделяемых данных нет. В этом случае балансировщик нагрузки может пробрасывать запросы на любую ноду кластера. Масштабируемость в этом случае ограничивается сверху затратами на загрузку сессионных переменных из базы или с разделяемого диска.
Замечу, что in-memory replication работает все-же быстрее, чем загрузка сессионных переменных с NFS или из БД, и ее можно реализовать в PHP при помощи memcache (http://www.php.net/memcache).

Есть однако и другие виды кластеризации. Например распределенный реплицированный транзакционный кеш для разгрузки базы данных на чтение (см. например JBoss Сache).

Или кластеризация бизнес-объектов, которая имеет смысл в случае, если вычисления, выполняемые на ноде, длительные(например построение отчета).

В общем, много в этой области всего интересного :)
Спрашивайте, по мере сил отвечу...

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

непонял как субд может ограничитть маштабируемость ... ну не справляется mysql ... ставим oracle

мне казалось memcache это просто вариант для stateless php не сохранять сесию на hdd/bd а удержать в локальной памяти ... как-то невидно больших преимуществ реплицировать эту память. с субд будет тоже самое, сесия попадет в кеш субд/fs и будет считана из кеша субд/fs при следующем клике.

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

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

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

Minotaurus.

Времени мало. пора домой. Буду отвечать коротко.

>>непонял как субд может ограничитть маштабируемость ... ну не справляется mysql ... ставим oracle Да. При условии, что на него есть деньги. И на железо под него.

>>мне казалось memcache это просто вариант для stateless php не сохранять сесию на hdd/bd а удержать в локальной памяти ... как-то невидно больших преимуществ реплицировать эту память. с субд будет тоже самое, сесия попадет в кеш субд/fs и будет считана из кеша субд/fs при следующем клике.

С сайта проекта (http://www.danga.com/memcached/) memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

>>а зачем разгружать то что именно для этого создавалась ? никто лучше субд с чтением не справится. Тут тяжело спорить. Ваша точка зрения тоже имеет право на жизнь. Все зависит от обстоятельств. Применить можно оба подхода.

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

>непонял как субд может ограничитть маштабируемость ... ну не справляется mysql ... ставим oracle

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

Горизонтальное масштабирование делать несколько сложнее, но просто для хранения сессионных параметров тоже довольно просто (как самый простой вариант "диапазонная разбивка" по серверам).

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

вы не правы, во первых уперется в оракл на этой задаче невозможно. тут нет конкурентного доступа, значит маштабируется не хуже tpc-c т.е. линейно. в tpc-c есть тест из 64-нод RACа, т.е. вы можете понатыкать 64-ноды х 128-core power5 :) поверьте для хранения сессии этого вам хватит.

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

Minotaurus.

2Spice

про мемкеш, на первый взгляд это именно то что я предполагал - обычный демон который висит на обычном порту (т.е. принципиально ничем не отличается от субд). что вы имели ввиду под "in-memory replication" ?

Minotaurus.

>вы не правы, во первых уперется в оракл на этой задаче невозможно. тут нет конкурентного доступа, значит маштабируется не хуже tpc-c т.е. линейно. в tpc-c есть тест из 64-нод RACа, т.е. вы можете понатыкать 64-ноды х 128-core power5 :) поверьте для хранения сессии этого вам хватит.

Вы можете помимо всего прочего уперется в I/O. А насчет 64-нодов и всё такое я и писал - что это вертикальное масштабирование.

>но на самом деле все действительно гораздо проще, оракл не нужен у сесии есть ID, по которому можно просто раскидывать по серверам субд несвязываясь ни с ораклом ни с кластерами, причем совершенно неограничено :)

Всё правильно - это один из вариантов "диапазонного" горизонтального масштабирования, как я и сказал.

>вы не правы, во первых уперется в оракл на этой задаче невозможно. тут нет конкурентного доступа,

В догонку еще пояснения насчет конкурентного доступа: - как минимум индекс по Session Id

Вы будет их как минимум создавать, модифицировать по Id, чистить устаревшие (job'ой или еще чем).

А про I/O еще я сказал...

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

Да что-ж такое :-) Забыл сказать что при этом будет конкурентный доступ к индексу хотя-бы.

2akira_ag

вы не поняли - RAC это кластер, т.е. именно горизонтальное маштабирование и в i/o он никак не упрется, на 64 ноды можно терабайты оперативки насувать, до hdd дело не дойдет ...
конкурентным доступом называют борьбу за ресурс, тут же один юзер на одну сесию и никакой конкуренции ;)

>вы не поняли - RAC это кластер, т.е. именно горизонтальное маштабирование и в i/o он никак не упрется, на 64 ноды можно терабайты оперативки насувать, до hdd дело не дойдет ... конкурентным доступом называют борьбу за ресурс, тут же один юзер на одну сесию и никакой конкуренции ;)

Я знаю что такое RAC - кластер он довольно условный, и если внимательно присмотритесь увидите там единое хранилище и понятия "главного". А 64 ноды я подозреваю чисто теоретическое ограничение, и в реальности упрется гораздо быстрее, т.к. все узлы согласовывают своё поведение через одного.

-- akira_ag

Можете почитать это как в доке Оракла, так и в некоторых публикациях РДТЕХа на русском: http://www.rdtex.ru/download/RAC030205.pdf

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

RAC это shared-disk cluster, который сочитает в себе failover cluster и load balancing, т.е. это скорее у всех остальных субд кластер "довольно условный", т.к. скорее напоминает партитионинг, чем кластер. Именно поэтому RAC пока единственый кто применяется в реальных задачах (ebay, amazon, dell). Да никакого "главного" в RAC нет :)

что я дожен был увидеть "в некоторых публикациях РДТЕХа" ... непонял.

Minotaurus.

>Да никакого "главного" в RAC нет :)

Главный - это тот который отвечает за блокировки, и он есть.

>RAC это shared-disk cluster, который сочитает в себе failover cluster и load balancing, т.е. это скорее у всех остальных субд кластер "довольно условный", т.к. скорее напоминает партитионинг, чем кластер. Именно поэтому RAC пока единственый кто применяется в реальных задачах (ebay, amazon, dell).

Я не сравниваю его с остальными СУБД и не собираюсь вступать в религиозные войны. Архитектурно он кластер условный, т.е. имеет существенные отличия, о которых я и говорил. Если сравнить подход RAC и обычный по критериям, то ограничений у RAC больше и есть точки отказа. Именно поэтому я давал ссылку - там есть картинка и пару слов, чтобы много не читать.

>и есть точки отказа.

Насчет них возможно переборщил - их может и нету, говорят что RAC умеет глобальные службы в runtime менять мастера. Но надо проверять :-)

Мне тоже туда не хочется углублятся, поэтому давайте вы хотя бы ссылки приведеные вами же прочтете :) в двух словах:
на каждой ноде свой кеш, который _синхронизируется_ между нодами. кластер выживает при потери любой ноды, никакой single point of failure там нет. самое слабое звено - общее хранилище, но его можно дублировать милоном способов, хоть через атлантику.
короче RAC это класический кластер, который вполне маштабирутся горизонтально.

Мне тоже туда не хочется углублятся, поэтому давайте вы хотя бы ссылки приведеные вами же прочтете :) в двух словах:
на каждой ноде свой кеш, который _синхронизируется_ между нодами. кластер выживает при потери любой ноды, никакой single point of failure там нет. самое слабое звено - общее хранилище, но его можно дублировать милоном способов, хоть через атлантику.
короче RAC это класический кластер, который вполне маштабирутся горизонтально.

>Мне тоже туда не хочется углублятся, поэтому давайте вы хотя бы ссылки приведеные вами же прочтете :) в двух словах: на каждой ноде свой кеш, который _синхронизируется_ между нодами. кластер выживает при потери любой ноды, никакой single point of failure там нет. самое слабое звено - общее хранилище, но его можно дублировать милоном способов, хоть через атлантику. короче RAC это класический кластер, который вполне маштабирутся горизонтально.

Ну как же это классический кластер-то с общим единым местом - это кластер для CPU и для кеша в памяти :-) Еще redo-логи вроде держать может. Классическим явно не обзовешь :) Насчет single point уже сказал - что да его нету - попутал.

а вы где-то видели кластер без единой файловой системы :) ?

похоже вы так и не почитали даже концептс, неважно где и как организовано это единое хранилище, если хотите, можете разместить на кластной файловой системе, например на oracle cluster FS ...

Minotaurus.

>а вы где-то видели кластер без единой файловой системы :) ?

Кластер - может вообще быть без хранилища, или иметь его локально! Не вся жизнь ведь в БД.

>а вы где-то видели кластер без единой файловой системы :) ?

Мы вообще может говорим о разных вещах, я о кластере, который кластер в общем виде, а не только как хранилище. Т.е. об этом http://en.wikipedia.org/wiki/Computer_cluster

>Кластер - может вообще быть без хранилища, или иметь его локально! Не вся жизнь ведь в БД.

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

Minotaurus.

>Мы вообще может говорим о разных вещах, я о кластере, который кластер в общем виде, а не только как хранилище.

а RAC у вас теперь только хранилище :) ? оригинально :))

>ну может какие-то собраные на коленках и не имеют, но большинство промышленых кластеров имеют общую фс в том или ином виде...

Общая ФС это опция которая нужна или не нужна в зависимости от решаемых задач.

>а RAC у вас теперь только хранилище :) ? оригинально :))

И как для разработчика еще RAC может помочь помимо представления моих данных как единое целое? Или вы уже про Grid? Тогда нужно предупреждать.

В догонку "Oracle RAC is a cluster database with a shared cache architecture that overcomes the limitations of traditional shared-nothing and shared-disk approaches to provide highly scalable and available database solutions for all your business applications." http://www.oracle.com/technology/products/database/clustering/index.html

>Общая ФС это опция которая нужна или не нужна в зависимости от решаемых задач.

ОК, т.е. вы согласны что единое хранилище в RAC это никак на "кластерность" не влияет ? да наверно какие-то мелкие кластеры могут и по майлу рссылать результаты труда...

>И как для разработчика еще RAC может помочь помимо представления моих данных как единое целое? Или вы уже про Grid? Тогда нужно предупреждать

да какая разница что там делает RAC, может он просто html рисует для веба (есть такое htmldb, теперь apex завется заменитель php по сути) или космические вычисления делает в pl/sql :)
а как это называть grid cluster, failover cluster, load balancer решают маркетологи ... но как бы они не назвали суть не меняется.

>В догонку "Oracle RAC is a cluster database"

я правильно понял вы наконец увидели в RAC cluster :) и здаетесь :) ?

Minotaurus.