SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 74
  1. #26
    SitePoint Zealot
    Join Date
    Aug 2002
    Posts
    178
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    RAM disk would be fast, but don't forget memcahce - wikipedia, slashdot and livejournal are using it: http://pecl.php.net/package/memcache, home page: http://www.danga.com/memcached/

  2. #27
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Another solution; again a sub-system that is not language specific. Interesting because you can spread the cache across multiple servers. More complex and powerful than the simple, single server, RAM disk solution. Thanks nucleuz.

  3. #28
    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

  4. #29
    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

  5. #30
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Even if you're right, switching to Java might not be a viable option.
    Then solve it using a PHP style solution (and there are many) don't ask for servlets, threads, multiple inheritence, etc. etc.

    For example, if you want failover for sessions then store them in a database and use one of the many failover solutions for databases.

  6. #31
    SitePoint Member
    Join Date
    Jul 2004
    Location
    Netherlands
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like the idea of having the possibility of running php in a servlet-like engine. I'm thinking of proper control over thread sensitive applications, real-time systems etc.

    Saying that one could use Java is true, but not an argument for why PHP couldn't benefit from having such an engine. Where Java is heavy weight and might scare users off, I think PHP should focus on being lightweight, flexible, powerfull and accessible. Just like what PHP makes a success today.

    It may also give PHP a new boost in terms of establishing one very strong framework (or framework standard/specification) and improve the enterprise readiness of PHP. That could become a 'plus' over the numerous Java solutions out there (Tomcat, WebLogic, WebSphere etc).

    I'd like to pose a new question to this very interesting discussion: how would you see a serphplet being realized? Would this be similar to PHP-GTK? Would this be OO only, or also procedural (begin, end, wait, goto...)?

  7. #32
    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 vargo

    Saying that one could use Java is true, but not an argument for why PHP couldn't benefit from having such an engine. Where Java is heavy weight and might scare users off, I think PHP should focus on being lightweight, flexible, powerfull and accessible. Just like what PHP makes a success today.
    Well, but if you have to work with different framework and etc. I wouldn't say that it's very lightweight and easy for beginners.

    Quote Originally Posted by vargo

    I'd like to pose a new question to this very interesting discussion: how would you see a serphplet being realized? Would this be similar to PHP-GTK? Would this be OO only, or also procedural (begin, end, wait, goto...)?[/
    Serphplet? If you mean servlet, then why on earth do you nead PHP-GTK for that?

  8. #33
    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
    Then solve it using a PHP style solution (and there are many) don't ask for servlets, threads, multiple inheritence, etc. etc.
    Maybe you're right. I'm not advocating anything; I'm deliberately keeping an open mind about it because I don't think I have enough information to decide. There may be circumstances in which a PHP servlet engine would be useful.
    Quote Originally Posted by arborint
    For example, if you want failover for sessions then store them in a database and use one of the many failover solutions for databases.
    Yes, I was implying just that. I don't think you understood the intent of my comment. I wasn't touting the superiority of J2EE, I was pointing out the similarity to what you can do in PHP.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  9. #34
    SitePoint Member
    Join Date
    Jul 2004
    Location
    Netherlands
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mike Borozdin
    Well, but if you have to work with different framework and etc. I wouldn't say that it's very lightweight and easy for beginners.
    True. But I didn't say it would be easy. There's no way any beginner will have an easy time on complex material. In my opinion, php and java are just tools. And, like mentioned earlier in this thread, a servlet engine would just be another 'feature' of the product PHP.
    Edit2: I do think the implementation should be the KISS (Keep It Simple Stupid) way.
    Quote Originally Posted by Mike Borozdin
    Serphplet? If you mean servlet...
    Mind the winking smiley..
    Quote Originally Posted by Mike Borozdin
    , then why on earth do you nead PHP-GTK for that?
    Well, because the lifecycle of a servlet (http://www-306.ibm.com/software/webs.../wastutor8.htm) resembles that of an application (PHP-GTK) more than a script that gets executed within the webserver environment.
    Edit: I'm not saying that php-gtk should be used, but that some of the thoughts/ideas behind it may turn up again in a php servlet engine...


    By the way: http://sourceforge.net/projects/phplet/
    Last edited by vargo; Oct 25, 2004 at 04:38. Reason: extra comment

  10. #35
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  11. #36
    SitePoint Member
    Join Date
    Oct 2004
    Location
    canada
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have modified PHPLet and cleaned it up some and it only handles sequential requests (as PHPLet also had multiple processes, which I took out, but could put back in). I also added session management and a database pooling. The only real problem I have found is that any modifications you make to your servlet class requires the service to be restarted because once the servlet class has been included() it cannot be unloaded.

    If there is much interest I can create a sourceforge project and put the code up.

    Derek

  12. #37
    SitePoint Zealot
    Join Date
    Aug 2002
    Posts
    178
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dcomartin
    The only real problem I have found is that any modifications you make to your servlet class requires the service to be restarted because once the servlet class has been included() it cannot be unloaded.
    Derek
    that's not the whole truth, but: then you would rely on Classkit to be on the server.... ( point is: you can, if you really want to )

  13. #38
    SitePoint Member
    Join Date
    Oct 2004
    Location
    canada
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Renaming the class solves the problem but it won't remove it from memory which is what the ideal solution would be.

  14. #39
    SitePoint Enthusiast BDKR's Avatar
    Join Date
    Sep 2002
    Location
    Clearwater, Florida
    Posts
    69
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Finally! All of this chatter and nobody knew of this?

    The only reason I can see going against something like a PHP servlet engine, which is essentially what SRM (the above link) is, are the potential problems of running these in LVS style clusters. If I'm not mistaken, this is something the JavaServlet people still have not figured out.

    Anyway, with an LVS style cluster can come the idea or concept of shared nothing, which makes these systems simpler and more robust in terms of dealing with failure (not including the database level). The drawback here being that there is no persistence the way the Java guys want to see it, nor is there any true persistence across the entire web pool (or server farm) other than the database, at which point, you are still dealing with serialization. OTOH, msessions looks to be a good solution for this issue in the future. I just don't know if they yet have an automatic fail over mechanism.

    Anyway, SRM development has been dead for some time, which is a damn shame. Something like this, with the incorporation of msessions and persistent connetion(s) to a database (as opposed to the connect-query-dis-connect pattern) would be a boon for PHP development in load balanced highly available setups.

    Cheers,
    BDKR
    If you're not on the gas, you're off the gas!

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

    And of course there is a new version of PHP this time around...

    Quote Originally Posted by BDKR
    Anyway, SRM development has been dead for some time, which is a damn shame. Something like this, with the incorporation of msessions and persistent connetion(s) to a database (as opposed to the connect-query-dis-connect pattern) would be a boon for PHP development in load balanced highly available setups.
    For sure. Remember, SRM is based on PHP4. PHP5 brings with it a host of advantages which would warrent re-visiting this or similar concept.

    DB connection pooling would be a major major boon for database performance and connection management. At the moment running out of connections with pconnects can be a real possibility unless db config and web server config is tightly controlled by a very aware sys-admin/dba (who work closely together). Even so, you still have to make compromises on what would be an optimal upper limit for allowed connections.

    A system like msession the protocol would be able to be implemented as part of the container itself (rather than as a separately managed extension).

    At the point is, none of this is possible while running PHP in any of the currently available modes - cgi, module, sapi...

    The only disadvantage I suspect is the fact that long-running scripts may be more prone to memory leaks. This is more of an issue since PHP has so many extensions, adding to the probablity that at least one of them may be buggy if used by a long-running script. This fear could be unfounded but it may be a possibility.

  16. #41
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The DB connection pooling issue to deal with sites with a very high number of connections is the first thing that I have heard that sounds like a real problem. I am not sure it is a very common problem though.
    At the moment running out of connections with pconnects can be a real possibility unless db config and web server config is tightly controlled by a very aware sys-admin/dba (who work closely together).
    I think on this type of site you would expect very aware sys-admin/dba types to work closely together.

    I am still looking for something that is not a solution in search of a problem.

  17. #42
    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 arborint
    The DB connection pooling issue to deal with sites with a very high number of connections is the first thing that I have heard that sounds like a real problem. I am not sure it is a very common problem though. I think on this type of site you would expect very aware sys-admin/dba types to work closely together.

    I am still looking for something that is not a solution in search of a problem.
    well there are obviously others who don't need to keep looking because it is obvious. The Servlet design pattern solves the same overall problem as CGI, apache modules, and SAPIs. The main difference is that it seems to be an evolutionary step ahead of the rest. Applying the same concept to PHP is merely brining PHP up to speed (for those who CHOOSE to use it). PHP has always been about choice, this is just yet another. If it were otherwise, we'd still be stuck with CGI. Fortunately, this is not the case because there are people who are willing to give things a go instead of coming up with existential counter aguements.

  18. #43
    SitePoint Enthusiast BDKR's Avatar
    Join Date
    Sep 2002
    Location
    Clearwater, Florida
    Posts
    69
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tezza
    Remember, SRM is based on PHP4. PHP5 brings with it a host of advantages which would warrent re-visiting this or similar concept.
    Yes, I know this. But neither should the focus be at the language level. It's my opinion that this should focus on the ability to provide something like a Script Running Machine / PHPservelet Server without regard to new or old features of the language. The things that make SRM a good idea today (PHP5) made it a good idea yesterday (PHP4).

    Quote Originally Posted by tezza
    DB connection pooling would be a major major boon for database performance and connection management. At the moment running out of connections with pconnects can be a real possibility unless db config and web server config is tightly controlled by a very aware sys-admin/dba (who work closely together). Even so, you still have to make compromises on what would be an optimal upper limit for allowed connections.
    Actually, I'm not talking about connection pooling. This may be splitting hairs here, but pooling implies multiple connections. I am talking about only one (an ideal of course) connection to the database. So, for example, in the case of SRM, it would make one connection to the database that the application works against when it starts. Everytime a page request happens that requires retrieval of data from the db, the connection allready exists and the script just uses it's connection ID made available by SRM.

    What if there are multiple databases and multiple users? Well, that's still not a problem. In the case of MySQL, there will still be only one connection to the server, but I won't go into details. With Postgres on the other hand, you will need a connection for each database in use, unless something has changed on me.

    Quote Originally Posted by tezza
    A system like msession the protocol would be able to be implemented as part of the container itself (rather than as a separately managed extension).
    Err..., ? This looks and smells like an OO centric view, which I reject on the grounds that some may not wish to use OO. This should be an engine level (in the case of this example, the engine is SRM) feature so a developer can choose to use/implement it in whatever programming paradigm he or she prefers.

    Quote Originally Posted by tezza
    At the point is, none of this is possible while running PHP in any of the currently available modes - cgi, module, sapi...
    If it was, would this discussion exist? :-)

    Quote Originally Posted by tezza
    The only disadvantage I suspect is the fact that long-running scripts may be more prone to memory leaks. This is more of an issue since PHP has so many extensions, adding to the probablity that at least one of them may be buggy if used by a long-running script. This fear could be unfounded but it may be a possibility.
    The potential of memory leaks is real, but it's real in any application that's based on C (you don't think SRM is written in PHP do you?). But of course, that shouldn't stop anyone from constructing something as such.
    If you're not on the gas, you're off the gas!

  19. #44
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    While it would still require serialization (although in a somewhat different and more expandable form) a well written SOAP (or REST for you nuts out there) based web-service could function to create "pseudo-persistence" in an application. The advantages to a webservice are that you can use Apache (or IIS) as the "app server" and it's already well documented and mature.

    The downsides to this approach are obviously overhead and depending on implementation, flexibility. It is still a viable, already available alternative to the "servlet" approach.

  20. #45
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The main difference is that it seems to be an evolutionary step ahead of the rest.
    Or a previous step, depending on how you look at it.

  21. #46
    SitePoint Member danswebs's Avatar
    Join Date
    May 2004
    Location
    Greenville SC
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up Database Pooling

    Quote Originally Posted by dcomartin
    I have modified PHPLet ... added session management and a database pooling. ...
    If there is much interest I can create a sourceforge project and put the code up.

    Derek
    I am interested! Especially in the database pooling. This sounds like what I have been looking for.

    Dan

  22. #47
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Bogota
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BDKR
    Actually, I'm not talking about connection pooling. This may be splitting hairs here, but pooling implies multiple connections. I am talking about only one (an ideal of course) connection to the database. So, for example, in the case of SRM, it would make one connection to the database that the application works against when it starts. Everytime a page request happens that requires retrieval of data from the db, the connection allready exists and the script just uses it's connection ID made available by SRM.
    Are you sure about this? Having only one connection shared between every request could cause a bunch of requests waiting for a single query to be executed.

    This is why I prefer a connection pool in a shared memory context: If I ask for a connection, the pool will see if there's one free and give it back to me, if not it will create a new one, so I don't need to sit and wait.

    Actually I think this is the way persistent connections are handled (anyone know for sure?)

    Regards,
    - Andres
    If I have wings, why am I walking?

  23. #48
    SitePoint Member danswebs's Avatar
    Join Date
    May 2004
    Location
    Greenville SC
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Persistent Connections

    Quote Originally Posted by otnemem
    ...Actually I think this is the way persistent connections are handled (anyone know for sure?)
    My understanding of persistent connections is basically what you said. When a request is sent, the engine looks to see if a persistent connection is available with the same connection information. If one is available, it returns the handle. If it is not available, it creates one (up to the max limit of connections). Once the query ends, the handle is released back to the "pseudo pool."

    I also understand that there could be issues with apache holding on to child processes (idle ones) and potentially causing actual available connections to be reduced. This is where tuning Apache comes in. The fewer "minimum processes" available, the better. Hopefully the DBA and the Sys Admin are good friends.

    ~Dan
    Last edited by danswebs; Dec 1, 2004 at 13:17.

  24. #49
    SitePoint Enthusiast hantu's Avatar
    Join Date
    Oct 2004
    Location
    Berlin
    Posts
    54
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Connection pooling

    http://sqlrelay.sourceforge.net/ (including an API for PHP)

  25. #50
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BDKR
    Y
    Actually, I'm not talking about connection pooling. This may be splitting hairs here, but pooling implies multiple connections. I am talking about only one (an ideal of course) connection to the database. So, for example, in the case of SRM, it would make one connection to the database that the application works against when it starts. Everytime a page request happens that requires retrieval of data from the db, the connection allready exists and the script just uses it's connection ID made available by SRM.
    hum? what about transactions? if you have a single connection for all requests this will give more than a bit of trouble... bad idea imho.

    cheers
    Sike


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
  •