Caucho Resin adds PHP Go to top ] Posted by: Emil Kirschner

Posted on: December 19 2005 09:26 EST

in response to Mark N But won't that (Java specific PHP) take away from the attraction of PHP? One of the biggest reasons people use PHP is because it can run on just Apache (+ mod).

No, it doesn't take away any abstraction. It's just yet another platform on which you php code runs. (6x faster :-) ). Its just like running PHP on top of IIS.



It doesn't mean you cannot run you php code on apache /mod_php any more.



cheers,

Emil No, it doesn't take away any abstraction. It's just yet another platform on which you php code runs. (6x faster :-) ). Its just like running PHP on top of IIS.It doesn't mean you cannot run you php code on apache /mod_php any more.cheers, Reply to this Reply to original

Caucho Resin adds PHP Go to top ] Posted by: Juozas Baliuka

Posted on: December 19 2005 10:10 EST

in response to Emil Kirschner If you will wrapp and install java modules as PHP libraries then probably it will run on plain apache web server too. But I do not think it is a good idea, it must be very slow to load JVM per web server process or to use some fake server to run java functions.

This stuff just can help to migrate legacy PHP applications or can help to train PHP developers for j2EE, but opposite doe's not make sence. Reply to this Reply to original

Caucho Resin adds PHP Go to top ] Posted by: Emil Kirschner

Posted on: December 20 2005 05:05 EST

in response to Mark N It doesn't mean you cannot run you php code on apache /mod_php any more.cheers It does if you use things that are not available on apache/mod_php.

Hmmmm. I think your image of PHP is way to idealistic Sir. Let's consider this, for example: PHP offers support for calling COM component and also offers IIS specific functions. If you use IIS functions in your PHP code you can forget about running your code on apache. Also, if call COM components from your PHP code it will probably work from mod_php on apache on windoze, but don't dream about running it on linux.



So now considering all this, how doesn this java port take away more "attraction" from PHP?



Regards,

Emil Hmmmm. I think your image of PHP is way to idealistic Sir. Let's consider this, for example: PHP offers support for calling COM component and also offers IIS specific functions. If you use IIS functions in your PHP code you can forget about running your code on apache. Also, if call COM components from your PHP code it will probably work from mod_php on apache on windoze, but don't dream about running it on linux.So now considering all this, how doesn this java port take away more "attraction" from PHP?Regards, Reply to this Reply to original

Caucho Resin adds PHP Go to top ] Posted by: Mark N

Posted on: December 20 2005 13:06 EST

in response to Emil Kirschner So now considering all this, how doesn this java port take away more "attraction" from PHP?

I didn't say the port did - the java specific could would. And your above (not reposted) statements add to what I said.



I doubt I am idealistic about PHP. I was merely commenting on the idealistic view of others (ie it is easy and is supported everywhere). I didn't say the port did - the java specific could would. And your above (not reposted) statements add to what I said.I doubt I am idealistic about PHP. I was merely commenting on the idealistic view of others (ie it is easy and is supported everywhere). Reply to this Reply to original

PHP Multi-threaded problems Go to top ] Posted by: Matt Giacomini

Posted on: December 19 2005 10:37 EST

in response to Cameron Purdy Ok this may be a very stupid question, and if so I'm sorry for posting it, but:



I heard that most .php guys don't use Apache 2.0, because most of the php libs are not thread safe. So my first question is what about all the php libs, can they also be run in Resin's php server, do you just need to download the source for them and compile them in there too. My second question is by bringing libraries over from regular php to java php how does that affect the multithreaded problems that many/most php libraries suffer from? Reply to this Reply to original

PHP Multi-threaded problems Go to top ] Posted by: Aapo Laakkonen

Posted on: December 19 2005 12:31 EST

in response to Matt Giacomini Ok this may be a very stupid question, and if so I'm sorry for posting it, but:I heard that most .php guys don't use Apache 2.0, because most of the php libs are not thread safe.

This might cause you problems if you run Apache 2 threaded MPM. Most *nix distros offer preforked Apache 2 binaries by default (as in Apache 1.3.x)). Preforked MPM is also the most performant in my opinion in single processor machines and Apache is usually placed in the front (or in farm) and those machines are usually cheap single processor machines.



And saying "most of the php libs" is false. Most of PHP libs are already thread safe. All libs are not, but those modules are usually written by some 3rd party. I have been running mod_php with prefork MPM and worker MPM in apache 2 and both have been very reliable. I just prefer prefork MPM.

My second question is by bringing libraries over from regular php to java php how does that affect the multithreaded problems that many/most php libraries suffer from?

Resin is threaded by default as I know so if PHP is run on same process (as it usually is in threaded environment) badly behaving PHP module might bring the whole resin down. I'm not sure what php modules resin supports in it's PHP implementation. This might cause you problems if you run Apache 2 threaded MPM. Most *nix distros offer preforked Apache 2 binaries by default (as in Apache 1.3.x)). Preforked MPM is also the most performant in my opinion in single processor machines and Apache is usually placed in the front (or in farm) and those machines are usually cheap single processor machines.And saying "most of the php libs" is false. Most of PHP libs are already thread safe. All libs are not, but those modules are usually written by some 3rd party. I have been running mod_php with prefork MPM and worker MPM in apache 2 and both have been very reliable. I just prefer prefork MPM.Resin is threaded by default as I know so if PHP is run on same process (as it usually is in threaded environment) badly behaving PHP module might bring the whole resin down. I'm not sure what php modules resin supports in it's PHP implementation. Reply to this Reply to original

PHP Multi-threaded problems Go to top ] Posted by: Stefano Bagnara

Posted on: December 19 2005 12:45 EST

in response to Aapo Laakkonen Resin is threaded by default as I know so if PHP is run on same process (as it usually is in threaded environment) badly behaving PHP module might bring the whole resin down. I'm not sure what php modules resin supports in it's PHP implementation.

Quercus (the php module for resin) does not load php modules.

Quercus simply provides a "native" java implementation for most php functions.



I already found a few bugs but IMHO they are small bugs with easy fixes. I think/hope we'll soon see a standalone release of the php compiler/interpreter.



Perhaps a BSF implementation is not so far (Quercus already provide the mustang's javax.script.ScriptEngineFactory implementation) Quercus (the php module for resin) does not load php modules.Quercus simply provides a "native" java implementation for most php functions.I already found a few bugs but IMHO they are small bugs with easy fixes. I think/hope we'll soon see a standalone release of the php compiler/interpreter.Perhaps a BSF implementation is not so far (Quercus already provide the mustang's javax.script.ScriptEngineFactory implementation) Reply to this Reply to original

Are PHP APIs supported? Go to top ] Posted by: Stefano Bagnara

Posted on: December 19 2005 10:53 EST

in response to Yuri Magrisso

I've found a few functions missing and I reported them to their bugtracker.



Their bugtracker runs mantis bt (PHP) running over their new php interpreter and it seems to work fine!



I don't know wether the supported php language is php 4 or php 5.



You can digg this here:

http://www.digg.com/programming/6_times_faster_PHP_interpreter_by_Resin_creators I tested it: it supports most php apis.I've found a few functions missing and I reported them to their bugtracker.Their bugtracker runs mantis bt (PHP) running over their new php interpreter and it seems to work fine!I don't know wether the supported php language is php 4 or php 5.You can digg this here: Reply to this Reply to original

Caucho Resin adds PHP Go to top ] Posted by: Cameron Purdy

Posted on: December 19 2005 12:41 EST

in response to Lars Stitz I'm still waiting for the headline "Is Java killing PHP?"

;-)



Point is that it's not "killing" anything, it's just broadening the range of choices available for running these applications. If you can support 6x as many PHP users on a Java app server as you can on a "native" Apache server, then why not move over to Java? Thanks to Java and the ingenuity of the Caucho team, the savings in hardware, rackspace, electricity and systems management will add up to millions of dollars for large-scale PHP systems.



Peace,



Cameron Purdy

: Clustered Shared Memory for Java ;-)Point is that it's not "killing" anything, it's just broadening the range of choices available for running these applications. If you can support 6x as many PHP users on a Java app server as you can on a "native" Apache server, then why not move over to Java? Thanks to Java and the ingenuity of the Caucho team, the savings in hardware, rackspace, electricity and systems management will add up to millions of dollars for large-scale PHP systems.Peace,Cameron Purdy Tangosol Coherence : Clustered Shared Memory for Java Reply to this Reply to original

Caucho Resin adds PHP Go to top ] Posted by: Stefano Bagnara

Posted on: December 19 2005 15:46 EST

in response to Scott Ferguson The benchmark was actually only 4x faster, and was done late at night in preparation for JavaPolis, so take it with a grain of salt.

Hei Scott,



can you reply to this questions?



1) what language specification did you implement? PHP4 or PHP5?



2) what is the compatibility status? Fully implemented modules, partially implemented, not implemented.



3) Is there any official/community website for quercus? (I've only found the bugtracker at



4) What is the quercus license? From the source comments I understand it's under the GPL: is it correct? Hei Scott,can you reply to this questions?1) what language specification did you implement? PHP4 or PHP5?2) what is the compatibility status? Fully implemented modules, partially implemented, not implemented.3) Is there any official/community website for quercus? (I've only found the bugtracker at http://bugs.caucho.com/my_view_page.php 4) What is the quercus license? From the source comments I understand it's under the GPL: is it correct? Reply to this Reply to original

Caucho Resin adds PHP Go to top ] Posted by: Scott Ferguson

Posted on: December 19 2005 17:03 EST

in response to Stefano Bagnara 1) what language specification did you implement? PHP4 or PHP5?

PHP 5. I don't believe there's an actual language specification, though. :)

2) what is the compatibility status? Fully implemented modules, partially implemented, not implemented.

We can add that to the wiki (wiki.caucho.com). The details would be too long to post here, since there are lots of PHP modules and functions. We're concentrating on finding and implementing the most-used functions first, so the function/module list looks pretty scattershot at the moment.



Because we're trying to identify the most-used functions first, having people add bug reports for functions they need is very valuable.







3) Is there any official/community website for quercus? (I've only found the bugtracker at http://bugs.caucho.com/my_view_page.php )

is the best at the moment other than the bug trackers. We'll be adding a bulletin board as soon as we find a good PHP one and make any Quercus fixes to get it working.

4) What is the quercus license? From the source comments I understand it's under the GPL: is it correct?

GPL PHP 5. I don't believe there's an actual language specification, though. :)We can add that to the wiki (wiki.caucho.com). The details would be too long to post here, since there are lots of PHP modules and functions. We're concentrating on finding and implementing the most-used functions first, so the function/module list looks pretty scattershot at the moment.Because we're trying to identify the most-used functions first, having people add bug reports for functions they need is very valuable. http://wiki.caucho.com is the best at the moment other than the bug trackers. We'll be adding a bulletin board as soon as we find a good PHP one and make any Quercus fixes to get it working.GPL Reply to this Reply to original

Caucho Resin adds PHP Go to top ] Posted by: Will Hartung

Posted on: December 19 2005 14:50 EST

in response to Cameron Purdy I'm still waiting for the headline "Is Java killing PHP?"

;-)



Point is that it's not "killing" anything, it's just broadening the range of choices available for running these applications. If you can support 6x as many PHP users on a Java app server as you can on a "native" Apache server, then why not move over to Java? Thanks to Java and the ingenuity of the Caucho team, the savings in hardware, rackspace, electricity and systems management will add up to millions of dollars for large-scale PHP systems.

Actually, Java is "adopting and extending" PHP ;-).



I think this will be a great way for folks to migrate to a Java solution, but I do not think that we'll be seeing this in the wild from generic PHP hosting providers any time soon.



Simply put, while it's great that Resin can run PHP (and Cold Fusion, for that matter), the Apache/PHP process model is a much safer system from a "general public, idiot user accidently DoSing the system" point of view.



But it's about time this happened. I always thought it was a smart move when ColdFusion jumped on the JVM, and I didn't see much of a reason why PHP couldn't have done the same thing.



The nice thing about this is that it will (ideally) let PHP application integrate much more smoothly with Java systems, and will let those who may feel "trapped" by PHP have a way out into the broader world that is Java. Actually, Java is "adopting and extending" PHP ;-).I think this will be a great way for folks to migrate to a Java solution, but I do not think that we'll be seeing this in the wild from generic PHP hosting providers any time soon.Simply put, while it's great that Resin can run PHP (and Cold Fusion, for that matter), the Apache/PHP process model is a much safer system from a "general public, idiot user accidently DoSing the system" point of view.But it's about time this happened. I always thought it was a smart move when ColdFusion jumped on the JVM, and I didn't see much of a reason why PHP couldn't have done the same thing.The nice thing about this is that it will (ideally) let PHP application integrate much more smoothly with Java systems, and will let those who may feel "trapped" by PHP have a way out into the broader world that is Java. Reply to this Reply to original

Caucho Resin adds PHP Go to top ] Posted by: Lars Stitz

Posted on: December 20 2005 03:53 EST

in response to Cameron Purdy Point is that it's not "killing" anything, it's just broadening the range of choices available for running these applications.

My point exactly. And if we broaden the term "these applications" to mean web applications in general, it is easy to see that tools like Ruby on Rails are not killing Java, but are just adding to the list of available technologies that a web developer can use to do his job.



I, for one, welcome any of our new web development tools that bring fresh ideas. (Call me pro-choice, if you like.) However, it is natural that too many choices will confuse some developers, or even frighten them -- add the FUD that TheServerSide spreads with their reoccuring "Is [technology X] killing Java?" posts and you'll have the liveliest "discussions"... Good for the ad sales revenue, I guess.



Please note: That a new tool is offered does not mean that the tools you use are obsolete now.



Just my two cents, Lars :-) My point exactly. And if we broaden the term "these applications" to mean web applications in general, it is easy to see that tools like Ruby on Rails arekilling Java, but are just adding to the list of available technologies that a web developer can use to do his job.I, for one, welcome any of our new web development tools that bring fresh ideas. (Call me pro-choice, if you like.) However, it is natural that too many choices will confuse some developers, or even frighten them -- add the FUD that TheServerSide spreads with their reoccuring "Is [technology X] killing Java?" posts and you'll have the liveliest "discussions"... Good for the ad sales revenue, I guess.Please note: That a new tool is offered does not mean that the tools you use are obsolete now.Just my two cents, Lars :-) Reply to this Reply to original

Cool, but benchmarks? Go to top ] Posted by: Aapo Laakkonen

Posted on: December 20 2005 05:23 EST

in response to Steve Lewis From what I understand, PHP can't run on Apache 2 yet. It's not multi-threaded capable yet.

PHP is, but not all it's 3rd party modules are and I doubt they never will (maybe they are not developed anymore). PHP team does not have any responsibility on modules provided by 3rd parties (and they do no officially support them). More from here:



So the options for Apache2 is to run it with PREFORK MPM (that is not multithreaded MPM and performs better that for eg. worker mpm that is threaded in single processor machines). Or you can run Apache2 threaded and use FastCGI module to execute PHP.



I'm not sure where this 6x performance gain was taken, but I think we need more information to justify this. I do know that bytecode compiled java code is most propably faster than evaluated PHP. Did you use PHP bytecode cache (that is used in all reasonable PHP configurations), eg. PECL/APC, eaccelerator etc?



Roadsend has gone even further than Caucho by compiling PHP to nativecode:



There is also PHP -> MS .NET Compiler that is also kinda fast:

You *could* use it, but it wouldn't be completely threadsafe.

I have been running mod_php on Apache 2 on both Worker MPM and Prefork MPM for over two years and I have not had a single crash because of PHP (but officially PHP team is still recommending Prefork MPM on Apache 2 installations that is perfectly fine for me. As I have said threading is not always better than multiple processes (eg. preforking).

So odds are they are experiencing a lot of speedup just from having the ability to run inside a multithreaded JVM.Steve

No, that is not the point. multithreading has nothing to do with this said performance boost. The whole point is that caucho is compiling PHP code to JVM bytecode (native Java code). Byte code is most definately faster to execute (even in slow JVM implementation) than parsing/evaluating PHP scripts on the fly. But as I said PHP has also these so called bytecode caches that compile PHP pages on background to their native bytecodes (eg. eaccelerator, pecl/apc, zend accelerator, etc.). I do not know did caucho use these when they did they tests against mod_php (if not, I do not think that this it's fair to compare the two). PHP is, but not all it's 3rd party modules are and I doubt they never will (maybe they are not developed anymore). PHP team does not have any responsibility on modules provided by 3rd parties (and they do no officially support them). More from here: http://www.php.net/manual/en/install.unix.apache2.php.and here: http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2 So the options for Apache2 is to run it with PREFORK MPM (that is not multithreaded MPM and performs better that for eg. worker mpm that is threaded in single processor machines). Or you can run Apache2 threaded and use FastCGI module to execute PHP.I'm not sure where this 6x performance gain was taken, but I think we need more information to justify this. I do know that bytecode compiled java code is most propably faster than evaluated PHP. Did you use PHP bytecode cache (that is used in all reasonable PHP configurations), eg. PECL/APC, eaccelerator etc?Roadsend has gone even further than Caucho by compiling PHP to nativecode: http://www.roadsend.com/home/index.php?pageID=compiler There is also PHP -> MS .NET Compiler that is also kinda fast: http://www.php-compiler.net/ I have been running mod_php on Apache 2 on both Worker MPM and Prefork MPM for over two years and I have not had a single crash because of PHP (but officially PHP team is still recommending Prefork MPM on Apache 2 installations that is perfectly fine for me. As I have said threading is not always better than multiple processes (eg. preforking).No, that is not the point. multithreading has nothing to do with this said performance boost. The whole point is that caucho is compiling PHP code to JVM bytecode (native Java code). Byte code is most definately faster to execute (even in slow JVM implementation) than parsing/evaluating PHP scripts on the fly. But as I said PHP has also these so called bytecode caches that compile PHP pages on background to their native bytecodes (eg. eaccelerator, pecl/apc, zend accelerator, etc.). I do not know did caucho use these when they did they tests against mod_php (if not, I do not think that this it's fair to compare the two). Reply to this Reply to original

Cool, but benchmarks? Go to top ] Posted by: Cameron Purdy

Posted on: December 20 2005 11:51 EST

in response to Aapo Laakkonen



I think you are missing something here. You say:

Roadsend has gone even further than Caucho by compiling PHP to nativecode

.. and ..

The whole point is that caucho is compiling PHP code to JVM bytecode (native Java code). Byte code is most definately faster to execute (even in slow JVM implementation) than parsing/evaluating PHP scripts on the fly. But as I said PHP has also these so called bytecode caches that compile PHP pages on background to their native bytecodes (eg. eaccelerator, pecl/apc, zend accelerator, etc.).

The point is actually that Java byte codes are native code, because all JVMs today that are being used in server environments will dynamically (either JIT or adaptively) compile the byte codes to native machine code. For most applications, "Java byte code" is now as fast as C code built with an optimizing compiler. That means that PHP running on Caucho is not just "being compiled to byte codes", but is actually "being compiled to native machine code", which is pretty quick.



Further, even if a different approach compiled to native code, Java would still likely be significantly faster, because (at this current point in time) JVMs have the best performance of any of the various high level languages that support JIT technology. The two main reasons why this is so is that the major hardware companies (Intel, Sun, IBM) have focused for the past ten years on making it so, and Java byte codes themselves are a decent match for machine code, so there are few major inefficiencies in the translation. (For the same reason, C used to be called "assembly with macros", since its supposedly high-level constructs were already well known to assembly programmers, and most had 1:1 translations to assembly.)



Peace,



Cameron Purdy

: The Java Data Grid Aapo,I think you are missing something here. You say:.. and ..The point is actually that Java byte codesnative code, because all JVMs today that are being used in server environments will dynamically (either JIT or adaptively) compile the byte codes to native machine code. For most applications, "Java byte code" is now as fast as C code built with an optimizing compiler. That means that PHP running on Caucho is not just "being compiled to byte codes", but is actually "being compiled to native machine code", which is pretty quick.Further, even if a different approach compiled to native code, Java would still likely be significantly faster, because (at this current point in time) JVMs have the best performance of any of the various high level languages that support JIT technology. The two main reasons why this is so is that the major hardware companies (Intel, Sun, IBM) have focused for the past ten years on making it so, and Java byte codes themselves are a decent match for machine code, so there are few major inefficiencies in the translation. (For the same reason, C used to be called "assembly with macros", since its supposedly high-level constructs were already well known to assembly programmers, and most had 1:1 translations to assembly.)Peace,Cameron Purdy Tangosol Coherence : The Java Data Grid Reply to this Reply to original

Cool, but benchmarks? Go to top ] Posted by: Aapo Laakkonen

Posted on: December 20 2005 18:34 EST

in response to Cameron Purdy Aapo,I think you are missing something here. You say: Roadsend has gone even further than Caucho by compiling PHP to nativecode

The point is actually that Java byte codes are native code, because all JVMs today that are being used in server environments will dynamically (either JIT or adaptively) compile the byte codes to native machine code.

I know that, but I still do not consider java bytecode as native code because there is always the JVM. I would propably consider Java bytecode as native code if JVM unloads itself after JITing. But that is not happening. And I said that roadsend has gone further than caucho. Caucho is not compiling anything to native code (JVM might do it... but that depends on JVM). They just turn PHP code to bytecode (or maybe java source and use javac to compile to bytecode).



But you are correct that todays applications run inside jvm are usually comparable to their native counterparts in performance. I have not seen many high end Java games, but on the server side Java seems to work as great as native code.



And thank you Cameron for clarifying the things I had forgotted or which I had given misinformation. I know that, but I still do not consider java bytecode as native code because there is always the JVM. I would propably consider Java bytecode as native code if JVM unloads itself after JITing. But that is not happening. And I said that roadsend has gone further than caucho. Caucho is not compiling anything to native code (JVM might do it... but that depends on JVM). They just turn PHP code to bytecode (or maybe java source and use javac to compile to bytecode).But you are correct that todays applications run inside jvm are usually comparable to their native counterparts in performance. I have not seen many high end Java games, but on the server side Java seems to work as great as native code.And thank you Cameron for clarifying the things I had forgotted or which I had given misinformation. Reply to this Reply to original

Caucho Resin adds PHP Go to top ] Posted by: Mileta Cekovic

Posted on: December 19 2005 14:42 EST

in response to Cameron Purdy Apparently, the PHP pages are compiled in the background to byte-code, and the resulting performance is six times that of Apache mod_php!

This is just another proof that JVM itself (either Sun, IBM or JRockit) IS VERY FAST, and that various layers/abstractions in some (not all) Java APIs are introducing overhead and slowliness! This is just another proof that JVM itself (either Sun, IBM or JRockit) IS VERY FAST, and that various layers/abstractions in some (not all) Java APIs are introducing overhead and slowliness! Reply to this Reply to original

Does this version of Resin run ONLY on Java 1.5? Go to top ] Posted by: D H

Posted on: December 19 2005 15:52 EST

in response to Cameron Purdy OK, so I downloaded the latest Resin to try this out. It refuses to run on Java 1.4.2, and after downloading the source and checking it out, it does appear that the Quercus piece that provides PHP functionality was written using generics.



I have a bit of a bone to pick with this since the docs that come with resin state it should run on Java 1.4 or higher and say nothing about a requirement for Java 1.5. Something else a bit galling is that the examples given on their site, judging from the output that's listed, give them impression that PHP support has been in for a couple of minor versions now; the messages specially mention Resin 3.0.14. That is likewise a non-starter, as trying to drop back to that version yields zilch in the way of the inclusion of Quercus.



So... for those who have tried this, am I just stuck short of moving to Java 1.5? Reply to this Reply to original