SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 74
  1. #1
    SitePoint Member deanpence's Avatar
    Join Date
    Oct 2004
    Location
    Brooklyn, NY
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    PHP Servlet Engine?

    Has anyone heard of any project designing such a thing (a la J2EE servlet engine)?

    And by "servlet engine", I mean a daemon that runs at least one PHP application and accepts requests to it. That is, a daemon would run (using some simple, standardized API) and load one or more PHP applications. Then, when the web server got a request for that servlet, it would pass it along to the servlet engine, which would then run the PHP application (only interpreting it once but executing many times), and, instead of forking more applications, it would (since we have good threading in the 2.6 kernel of Linux at least) create a new thread of the application for additional requests, sharing all application- and session-level data.

    With something like this, I would be much more at ease using PHP 5 to its potential.

  2. #2
    SitePoint Member
    Join Date
    Jun 2004
    Location
    Atlanta, GA
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sounds like Apache 2 (which is threaded, right?) and an opcode cache like turck mmcache (for the only interpreting once requirement). Granted, there's nothing defining an application/servlet structure for your scripts, but you might see that as beneficial (no such structure is imposed).

    By the way, turck provides a very nice cross-platform shared memory API for some interprocess communication, if you need it.

  3. #3
    Non-Member
    Join Date
    Oct 2004
    Location
    Net
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nver heard of such.

  4. #4
    ********* Wizard silver trophy Cam's Avatar
    Join Date
    Aug 2002
    Location
    Burpengary, Australia
    Posts
    4,495
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    I have but I can't think of the name right now...

  5. #5
    SitePoint Zealot tezza's Avatar
    Join Date
    Aug 2003
    Location
    Australia
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    as a PHP5 CLI implementation.

    Pretty cute idea if somewhat of an abomination. The new OO features in PHP5 (including interfaces and abstract classes) would make a resonably clean implementation of a PHPlet container as a PHP CLI socket server. As one way to do it...

  6. #6
    SitePoint Wizard Mike Borozdin's Avatar
    Join Date
    Oct 2002
    Location
    Edinburgh, UK
    Posts
    1,743
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deanpence
    Has anyone heard of any project designing such a thing (a la J2EE servlet engine)?

    And by "servlet engine", I mean a daemon that runs at least one PHP application and accepts requests to it. That is, a daemon would run (using some simple, standardized API) and load one or more PHP applications. Then, when the web server got a request for that servlet, it would pass it along to the servlet engine, which would then run the PHP application (only interpreting it once but executing many times), and, instead of forking more applications, it would (since we have good threading in the 2.6 kernel of Linux at least) create a new thread of the application for additional requests, sharing all application- and session-level data.

    With something like this, I would be much more at ease using PHP 5 to its potential.
    What is the purpose of having such a thing?

  7. #7
    SitePoint Member deanpence's Avatar
    Join Date
    Oct 2004
    Location
    Brooklyn, NY
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mike Borozdin
    What is the purpose of having such a thing?
    Well, first, as the complexity of the language increases, I find it much more difficult to justify using advanced OO language features that will be interpreted on every single request.

    Second, application-level and even (cached) session-level data can remain in memory instead of being loaded on every request.

    So, especially for larger, enterprise-level applications, you're ensured that there's minimal processor work required per-request.

    I use the J2EE servlet engine as an example because it's an excellent example of how this can be done. It just requires actual threading (or good interprocess communication, which is inferior) to share application-level data between threads.

  8. #8
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I use the J2EE servlet engine as an example because it's an excellent example of how this can be done.
    Not only is it an excellent example of how it can be done, it is done and is what you should use if you want to build applications in the style you describe. Java is easy to deploy and develop in, plus it is incredibly well supported.

    However, if you want to build applications where persistent application data is stored in standard subsystems like databases or a filesystem, where applications are built with basic OO language features plus a number of advanced procedural language features, and are built without having to resort to threading, then PHP is the system for you!

    Both are proven to be a scalable and enterprise ready. You lucky guy. You can take your pick.

  9. #9
    SitePoint Zealot tezza's Avatar
    Join Date
    Aug 2003
    Location
    Australia
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up

    Quote Originally Posted by arborint
    Not only is it an excellent example of how it can be done, it is done and is what you should use if you want to build applications in the style you describe. Java is easy to deploy and develop in, plus it is incredibly well supported.

    However, if you want to build applications where persistent application data is stored in standard subsystems like databases or a filesystem, where applications are built with basic OO language features plus a number of advanced procedural language features, and are built without having to resort to threading, then PHP is the system for you!

    Both are proven to be a scalable and enterprise ready. You lucky guy. You can take your pick.
    I disagree. I think a container for a servlet-type PHP scripts is a great idea. Put simply, it brings all the performance and scalability advantages that Java Servlet containers have to a huge user-base who like using PHP. There's nothing to say that the class interface needs to be exactly the same as HTTPServlet. As long as it is a life-cycle based API, the similarities can end there. There's always room for improvement. I think if someone wrote a thread/processor manager in C which loads the PHP engine and implements the API's life-cycle, it would kick **** on the Java equivilent.

    Basically you'd have the simplicity of PHP combined with the unparreleled speed of C and the zend engine. And then there's all those resource optimisation abilities of the C language that Java could not hope to emulate.

    It would take a long time to produce a product mature enough to use commercially, but I think it would be well worth it.

  10. #10
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "Basically" if you combine the simplicity of PHP with the complexity of Java and your get ... Java.

    My point was you already have a system that does what you want: Java. And it's really, really good for that style of implementation.

    There is also another system that works differently: PHP. If you don't like the shared nothing style then use Java or one of the may other options.

    If everything should be like Java, why are you using PHP? Not having things like servlets and namespaces and threads is what makes PHP unique and useful. The Zend guys can tell you why better than I can. I know lack of an app server is what made PHP so popular in virtual server hosting and perform so well. Lack of threading makes is so you can call any external code you want without it having to be thread-safe. That has opened up a lot more useful code to PHP. Add this stuff to PHP and you have two Javas and have lost PHP.

    You can put wings on a bulldozer or tracks on a airplane, but it does not make either better.

  11. #11
    SitePoint Member deanpence's Avatar
    Join Date
    Oct 2004
    Location
    Brooklyn, NY
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    "Basically" if you combine the simplicity of PHP with the complexity of Java and your get ... Java.
    I don't think this is about complexity.

    Quote Originally Posted by arborint
    My point was you already have a system that does what you want: Java.
    Strictly speaking, Java does not do this; a servlet engine and the Servlet API does it.

    Quote Originally Posted by arborint
    There is also another system that works differently: PHP. If you don't like the shared nothing style then use Java or one of the may other options.
    I really disagree with your characterization of PHP. As a language, it has nearly all the possibilities that Java has. Strictly speaking, the Java folks could have easily written an Apache module that would do a one-shot interpretation and execution just like PHP. That has nothing to do with the language and is a totally separate issue.

    Quote Originally Posted by arborint
    If everything should be like Java, why are you using PHP?
    What does it matter? PHP is still significantly different from Java, especially when it comes to typing. Compared to Java, PHP is very loosely typed, and I might prefer it over Java for enterprise-class apps if there were a servlet-type engine for it.

    Quote Originally Posted by arborint
    Not having things like servlets and namespaces and threads is what makes PHP unique and useful.
    Again, "servlets" are not part of the language. I think PHP should have (optional) namespaces, and I would be surprised if we didn't see POSIX threading capabilities in PHP soon.

    The way PHP is executed by the web server has nothing to do with the language itself. I'm not asking anyone to change the way PHP is executed. I'm just wondering if the servlet option is available.

    Quote Originally Posted by arborint
    The Zend guys can tell you why better than I can. I know lack of an app server is what made PHP so popular in virtual server hosting and perform so well.
    I think you'd find that Java performs extraordinarily well on the server, and the lack of an app server for PHP has just made it easier to program for (which is its biggest advantage over languages like Java).

    Quote Originally Posted by arborint
    Lack of threading makes is so you can call any external code you want without it having to be thread-safe. That has opened up a lot more useful code to PHP.
    I would agree that it's made PHP much easier to program for.

  12. #12
    SitePoint Wizard Mike Borozdin's Avatar
    Join Date
    Oct 2002
    Location
    Edinburgh, UK
    Posts
    1,743
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think arborint is right, you said you want a container for enterprise-level application, but if you develop such application, I think you can easily install an app server and use JSP/Servlet instead of PHP.

  13. #13
    Rabble Rouser bronze trophy
    Join Date
    Jan 2003
    Location
    Mountain View, CA
    Posts
    427
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mike Borozdin
    I think arborint is right, you said you want a container for enterprise-level application, but if you develop such application, I think you can easily install an app server and use JSP/Servlet instead of PHP.
    And we could also just use perl to munge up text for simple web sites, but we don't - we use php. The point that existing tools can do the job is moot.

  14. #14
    SitePoint Zealot tezza's Avatar
    Join Date
    Aug 2003
    Location
    Australia
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    CGI > module > SAPI > container - what's the problem?

    I think deanpeace deals with arboint's observations quite comprehensively so I won't try to make the same points over again. However, I think an analogy is in order.

    PHP started out as a CGI script. Now when someone came along and decided to make it into an apache module, someone could have said "wait a minute, if you want an apache module, you could just use mod_perl."

    What aborint is saying is the same thing. No one is talking about "Javar-ising" PHP. PHP will still be PHP if you ran your PHP scripts in a life-cycle container. I think you need to understand that life-cycle based containers a just a design pattern, not a new technology. I don't think there's anything wrong with borrowing the idea of the servlet framework design. People could have continued to build web apps with Java using CGI, but someone came up with a neat idea to make it more efficient - they didn't change the languge, they built a purpose-made framework to improve HTTP interaction. Building such a framework won't change PHP, it will still be the same simple language.

    The main difference will be that your PHP script doesn't have to terminate with every HTTP request. This can only be a GOOD thing. It has potential for massive performance/scalability improvements. At the moment, CGI, modules, and SAPI framweworks do not offer this due to their one-shot execution per request model.

  15. #15
    SitePoint Wizard Mike Borozdin's Avatar
    Join Date
    Oct 2002
    Location
    Edinburgh, UK
    Posts
    1,743
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Tezza, I don't mean that they are going to change the language, I'm just wondering if it's worth making efforts, 'cause you can just use JSP/Servlet for that.

  16. #16
    SitePoint Zealot tezza's Avatar
    Join Date
    Aug 2003
    Location
    Australia
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mike Borozdin
    Tezza, I don't mean that they are going to change the language, I'm just wondering if it's worth making efforts, 'cause you can just use JSP/Servlet for that.
    In my opinion, I suspect it is worth the effort. The performance improvements could be massive. It wouldn't be easy to implement though, there are a lot of issues to deal with. It should be pretty trivial to write a proof-of-concept with a command-line PHP socket listener, but this will never bring you the desired solution. Ultimately, the container will have to be written in C as are the apache modules and SAPI modules so that it can parcel off threads on an as-needed basis. Another advantage of this scheme is that we no longer have to rely on the web-server's memory management system. We'd be free to manage the memory resources how we want. We would also have the opportunity to improve the thread-safety for file-writes and other things like application level variables.

  17. #17
    SitePoint Wizard Mike Borozdin's Avatar
    Join Date
    Oct 2002
    Location
    Edinburgh, UK
    Posts
    1,743
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tezza
    In my opinion, I suspect it is worth the effort. The performance improvements could be massive. It wouldn't be easy to implement though, there are a lot of issues to deal with. It should be pretty trivial to write a proof-of-concept with a command-line PHP socket listener, but this will never bring you the desired solution. Ultimately, the container will have to be written in C as are the apache modules and SAPI modules so that it can parcel off threads on an as-needed basis. Another advantage of this scheme is that we no longer have to rely on the web-server's memory management system. We'd be free to manage the memory resources how we want. We would also have the opportunity to improve the thread-safety for file-writes and other things like application level variables.
    But can you tell me if this way has any advantages over JSP/Servlet, except for dynamic types that I can't name as an advantage?

  18. #18
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And we could also just use perl to munge up text for simple web sites, but we don't - we use php. The point that existing tools can do the job is moot.
    Actually my point was that it is WHY existing tools do the job that matters. Perl started as a better shell script. Java as a run anywhere C++. PHP as a easy to use CGI. And that is still pretty much where they still excel. Off course the OO guys whine for the same stuff everywhere and hence the confusion because languages start to look the same. But the systems those languages live in are very different.
    As a language, it has nearly all the possibilities that Java has. Strictly speaking, the Java folks could have easily written an Apache module that would do a one-shot interpretation and execution just like PHP. That has nothing to do with the language and is a totally separate issue.
    Everything may have the same possibilities but it is the choices that make the difference. No app server, threads, etc. are a few of the many decisions that make PHP the useful tool it is. There are other sets of tradeoffs you can make that are successful too. But there are always tradeoffs.
    The performance improvements could be massive.
    Proven not to be true. App servers are just a different way to achieve the same thing. If anything they often slow things down because of the overhead and complexity they add.

  19. #19
    Rabble Rouser bronze trophy
    Join Date
    Jan 2003
    Location
    Mountain View, CA
    Posts
    427
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Dude, are you ever going to stop *****ing about your nemesis "OO guys"?

  20. #20
    SitePoint Zealot tezza's Avatar
    Join Date
    Aug 2003
    Location
    Australia
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mike Borozdin
    But can you tell me if this way has any advantages over JSP/Servlet, except for dynamic types that I can't name as an advantage?
    Sure, the same advantages that PHP has over any other Java class. It will be PHP, not Java, so all the PHP advantages apply. It's easy to use, it doesn't have to be strictly OO, it has a big user-base, and is more fun than writing in a compiled language :-)
    I'm sure others have their own reasons why they prefer writing PHP scripts over Java classes. Using a framework won't alter this any more than other frameworks like WACT, Krysalis, papoon, Ambivilance or whatever...

    Alaso, a mature implementation of the idea may eventually be orders of magnatitude faster than Java.

  21. #21
    SitePoint Wizard Mike Borozdin's Avatar
    Join Date
    Oct 2002
    Location
    Edinburgh, UK
    Posts
    1,743
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tezza
    Sure, the same advantages that PHP has over any other Java class. It will be PHP, not Java, so all the PHP advantages apply. It's easy to use, it doesn't have to be strictly OO
    They are all subjective, except for big users base that can lead to creating some new technology, like PHP-servlet, I wrote about here

  22. #22
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think you are not really clear about what you are asking for. At the top you wanted " (only interpreting it once but executing many times)" (i.e. compiled) and at the end you like 'is more fun than writing in a compiled language."

    If you are looking for speed then use an accelerator and put your sesson files in a RAM disk. That wil achieve your goals of compile once and memory resident application data without having to turn PHP into Java.

    I guess it comes down to if you are interested in a specific method in achieving your goal, use a system that implements that method. If you are interested in achieving your goal using PHP, then find the PHP way to do it.

  23. #23
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    put your sesson files in a RAM disk.
    Now that is an interesting idea - remembering that you can put objects in a session variable.

    Douglas
    Hello World

  24. #24
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, you can serialize objects (with care). And getting data from a RAM file system is faster and lower overhead than going through an app server. The PHP Way is using existing and proven sub-systems not inventing new ones.

  25. #25
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    The PHP Way is using existing and proven sub-systems not inventing new ones.
    That is a global programming principle rather than something invented by PHP. It is better to re-use something that works than to fix the wheel which isn't broken.

    If anything, the "PHP Way" as you call it is more a case of making the wheel easier to use to aid re-use; the "proven sub-system" ideology of not reinventing things existed before PHP!

    Douglas
    Hello World


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •