SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 74

Hybrid View

  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 Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deanpence
    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.
    But wait a minute. I hear that the J2EE people brag that J2EE will transparently handle failover for them. So if you're using a Web app and the server you're connected to fails, you will notice nothing because another server takes over. I can't see how this is possible unless session data is stored somewhere other than in RAM on a specific server.

    The servlet engine idea may be a good one, but I think it needs to be explored in more detail before we can make educated guesses about just how good it is.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  9. #9
    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.

  10. #10
    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.

  11. #11
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    You're assuming that we're building something from scratch. Suppose we already have a working PHP application--perhaps a large one--and circumstances change so the "style you describe" becomes more relevant. Even if you're right, switching to Java might not be a viable option.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  12. #12
    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.

  13. #13
    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.

  14. #14
    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.

  15. #15
    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.

  16. #16
    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
    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.
    I don't want to use Java. I'm asking about PHP. It's a framework-level construct, not a language-level feature. In any hypothetical application, I want to use PHP, and I'm wondering if any servlet-style engine for PHP exists. I obviously know about the Java Servlet engine, and I don't want to use it.

  17. #17
    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.

  18. #18
    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.

  19. #19
    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.

  20. #20
    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?

  21. #21
    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.

  22. #22
    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

  23. #23
    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
    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?
    Loose typing is a huge advantage for those who want to use it. Not being Java is yet another (some folks just don't like it). Using PHP, an easy-to-write language, is another. Having server-level and application-level data stay in memory for the lifecycle of the app and having session-level data handled in many ways is another.

    I'm not sure why there's such a resistance to this idea. The implementation would be tough, sure, but the model is proven to work very well, and writing a PHP servlet app could be almost as easy as writing a plain PHP script.

  24. #24
    SitePoint Enthusiast hantu's Avatar
    Join Date
    Oct 2004
    Location
    Berlin
    Posts
    54
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deanpence
    ... writing a PHP servlet app could be almost as easy as writing a plain PHP script.
    I don't think so. In a Servlet container objects might live beyond a request and could be accessed by a lot of other objects at the same time. This means you will have to handle concurrency problems which is not a trivial issue.

  25. #25
    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.


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
  •