Re: [PHP4BETA] Re: ...Java components

garyb@fxt.com wrote: >I'm not an expert here, but I have dinked about with a couple of commercial server-side java >systems (Jrun and Dynamo). They both have a standalone server process with a small glue >module stuck into Apache to pass requests. This is analogous to database connections. It >appears to me that this approach miminizes the problems discussed here, in particular the >memory footprint and JVM startup overhead. However, the java engine consistently used up >5-12% of CPU just idling, sigh. The more I think about it, the more I think that Joe Walnes is right. In order to get maximum performance out of this, Java needs to be "on top". The difference between what I am trying to do and servlets is the granularity of the requests. With servlets, a request comes in. Then some processing, possibly quite significant, occurs in Java. Ultimately, a stream of bytes comes back and the request is complete. What I am trying to is more like NetScape JavaScript's LiveConnect function. In the middle of processing a single request a barrage of method calls are made with any number of parameters being passed on each request and possible an object being returned. The cross-process overhead would eat this alive. What is needed is for this script to be bound to single Java thread for the duration and a very low overhead mechanism for passing requests back and forth. While what I have implemented so far can be improved, it seems to me to be in the right direction. The picture that is forming for me is a three pronged approach: 1) Once completed, the support I have started so far is quite sufficient for cases where the preponderance of the web site is in PHP and where the usage of Java is casual or even incidental. I say casual, but I see no reason why this couldn't support request rates in terms of a single digit number of incoming requests per second. It certainly is not going to win any awards, but quite sufficient for many uses. 2) Where there is a more serious amount of Java involved, the right thing to do is to get one of those commercial server-side Java systems that you are referring to and let the professionals manage the interface between the http daemon and Java. When PHP logic is required, it can run "under" the servlet interface and enjoy the near native integration enjoyed by the first approach. In fact, it may be quite possible to make the support such that the PHP pages themselves won't require modification, the difference being whether you specify --with-apxs or --with-servlet on your ./configure. 3) Finally, true enterprise customers may find they need a 3-tier (or even n-tier) approach. A typical configuration would be a PHP web server talking to a back end mainframe or large Unix box. Certainly, this could be done with the second approach with the connection between the tiers being done in Java using IIOP, but if the only reason for Java on the middle tier in such a configuration is to package up requests, then better performance could be achieved by providing a CORBA module for PHP. Any and all feedback is welcome. It is always better to make mid course corrections earlier than later!