Caucho Resin adds PHP

Home

News: Caucho Resin adds PHP

  1. Caucho Resin adds PHP (43 messages)

    Caucho, the company behind the open source application server Resin and the open Web Services protocols Burlap and Hessian, has recently added PHP to its list of supported features. Apparently, the PHP pages are compiled in the background to byte-code, and the resulting performance is six times that of Apache mod_php!

    The PHP libraries for this implementation are apparently being written entirely in Java, and it sounds relatively simple to expose your own libraries to PHP code.

    With Python, PHP, and CFML supported in a Java application server environment, and the jRuby project not so far behind, it's starting to look like Java is the ideal platform for supporting all of the popular web development languages.

    Threaded Messages (43)

  2. Caucho Resin adds PHP[ Go to top ]

    And now this implementation can follow by the ColdFusion way: add filters and custom tags on the next step. So finally we will see J2EE PHP

    Marina
    Coldbeans
  3. Caucho Resin adds PHP[ Go to top ]

    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).
  4. Caucho Resin adds PHP[ Go to top ]

    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
  5. Caucho Resin adds PHP[ Go to top ]

    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.
  6. Caucho Resin adds PHP[ Go to top ]

    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.
  7. Caucho Resin adds PHP[ Go to top ]

    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
  8. Caucho Resin adds PHP[ Go to top ]

    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).
  9. Caucho Resin adds PHP[ Go to top ]

    This is very cool. You could have a PHP frontend and a Java backend very easily.

    Steve
  10. Caucho Resin adds PHP[ Go to top ]

    You could have a PHP frontend and a Java backend very easily.

    Sure! And a php developer can use enterprise class Java libraries simply and efficently! And java applications can now integrate classical php web stuff (php forums, php blogging tools).
  11. PHP Multi-threaded problems[ Go to top ]

    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?
  12. PHP Multi-threaded problems[ Go to top ]

    It looks like, you need to wrapp all libraries yourself and write some kind of descriptor to register static JAVA method as PHP function.
  13. PHP Multi-threaded problems[ Go to top ]

    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.
  14. PHP Multi-threaded problems[ Go to top ]

    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)
  15. Are PHP APIs supported?[ Go to top ]

    I think this is great news.

    Does it support the PHP APIs or only the PHP language?
    Which version of PHP is supported 4, 5?
  16. Are PHP APIs supported?[ Go to top ]

    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:
    http://www.digg.com/programming/6_times_faster_PHP_interpreter_by_Resin_creators
  17. Are PHP APIs supported?[ Go to top ]

    I tested it: it supports most php apis.

    Impressive! Thanks
  18. PHP 5 and libraries[ Go to top ]

    Resin PHP (we call Quercus) supports PHP 5 and also a growing number of the PHP libraries. We are adding to them daily.
  19. Caucho Resin adds PHP[ Go to top ]

    I'm still waiting for the headline "Is Java killing PHP?"...

    SCNR, Lars
  20. Caucho Resin adds PHP[ Go to top ]

    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
    Tangosol Coherence: Clustered Shared Memory for Java
  21. Caucho Resin adds PHP[ Go to top ]

    It is hard to believe this implementation is 6x faster, but Caucho produces very good software and it is a very good idea to implement PHP for servlet container.
  22. Caucho Resin adds PHP[ Go to top ]

    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. (As with all benchmarks.)

    The specific test case was the default mediawiki (wikipedia) home page on installation using "ab", the Apache benchmark program. So, it's a real application, not a synthetic benchmark.

    As always, benchmark values will vary widely depending on the application used, configuration, machine, etc, etc, etc.

    Warnings aside, it's still an interesting first datapoint.
  23. Caucho Resin adds PHP[ Go to top ]

    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 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?
  24. Caucho Resin adds PHP[ Go to top ]

    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 )

    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.
    4) What is the quercus license? From the source comments I understand it's under the GPL: is it correct?

    GPL
  25. Caucho Resin adds PHP[ Go to top ]

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

    I've submitted bugs found while trying to run drupal (the most used php "cms/framework" around).
  26. Caucho Resin adds PHP[ Go to top ]

    1) PHP 5

    2) Should be fully compatible, but please report any bugs.
    The list of fully / partially implemented modules is in quercus/classes/com/META-INF/services/com.caucho.quercus.QuercusModule.
    There are more modules to come....

    3) I think so far just the bugtracker.

    4) GPL
  27. I agree it's a nice feature, and that Caucho makes good software. No complaints at all there. But I hate to see big claims like 6x better performance without any substantiation.
  28. Caucho Resin adds PHP[ Go to top ]

    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.
  29. Caucho Resin adds PHP[ Go to top ]

    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 :-)
  30. Cool, but benchmarks?[ Go to top ]

    Cool features, kudos to the Resin crew. Where are the benchmarks showing the alleged 6x performance advantage over Apache 2.0? I couldn't find them on the Resin site or the digg.com report or Cameron's blog entry (where others have asked to see substantiation of this huge performance claim...)
  31. Cool, but benchmarks?[ Go to top ]

    From what I understand, PHP can't run on Apache 2 yet. It's not multi-threaded capable yet. You *could* use it, but it wouldn't be completely threadsafe.

    I may be wrong by now, my info is a few months old.

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

    Steve
  32. Cool, but benchmarks?[ Go to top ]

    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: 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/.
    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).
  33. Cool, but benchmarks?[ Go to top ]

    Aapo,

    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
    Tangosol Coherence: The Java Data Grid
  34. Cool, but benchmarks?[ Go to top ]

    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.
  35. Caucho Resin adds PHP[ Go to top ]

    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!
  36. 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?
  37. It was only released in 3.0.16. I was writing the wiki page before I knew what release we would actually include it in.
  38. Java Compatibility[ Go to top ]

    I have also heard that it does in fact only run on Java 1.5. Can anyone else confirm this? I've heard differing viewpoints on this. John | Skylight Windows
  39. PHP-Java Interaction[ Go to top ]

    Can Java and PHP be used in the same application, sharing scopes? That is, can PHP code put something in the session that is later retrieved by a Java session.getAttribute() call? Vice versa?
    Can PHP be used to simply render a Java-based model?
  40. Caucho Resin adds PHP[ Go to top ]

    Lol. We need a petshop in php that beats the hell out of .NET implementation! Right !?

    Regards,
    Horia Muntean
  41. Caucho Resin adds PHP[ Go to top ]

    Lol. We need a petshop in php that beats the hell out of .NET implementation! Right !?

    Working on it. :)

    Seriously, though, keep in mind that PHP is a dynamic language. That's true no matter whether the implementation is interpreted or compiled.

    For example, variable references in PHP resemble hashmap lookups, not local variable references. (In addition, PHP has a silly copy-on-assignment semantics for arrays which also affects performance.) That means the underlying performance issues aren't quite as simple as just compiling to bytecodes.

    In particular, even though Quercus compiles to Java bytecodes (and therefore to machine code through the magic of the JIT), an equivalent Java program will still be faster than the compiled PHP program. The compiled PHP program is basically doing hashmap lookups for variable references, while the Java program is using machine code local variable references.
  42. Caucho Resin adds PHP[ Go to top ]

    Maybe Fibonacci in java will be faster than in php. What about the layers that ( read Mr. Tate late night ROR application being faster than the java counterpart, which BTW I find hard to belive taken into account all the records BEA and Sun broke lately ) people say hamper the java web apps performance?

    Regards,
    Horia Muntean
  43. one interesting thing that I don't see emphatized enough is that now we can easily obtain load-balancing and redundance, which Resin offers to all hosted apps!

    btw: any attempt to obtain failover via TCP session sharing?
  44. Very old article....[ Go to top ]

    but interesting to read.

     

    Thanks, Mark