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.
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.
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).
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.
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.
If it was, would this discussion exist?
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.
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.
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?)
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.
If you mean one persistent connection per user (per instance of the application), then I see where you are going, but one single connection to the database full stop seems like a waste of the ability of the DB to handle multiple connections (as yuo may have multiple users).
I still don’t see how this is going to be much benifit: you still have to associate a request with a user, which is more of a bother than whether the PHP files are loaded from memory or from files - hell, why not just use the Zend Encoder and have the encoded files stored in memory? Seems much easier to do with the benifit that it will speed up any PHP application. Infact, I can hardly see why the servlet hosting code overhead is going to make anything faster than this anyway!
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.
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.
It’s worth noting that although PHP started as CGI, it’s (optionally) not CGI any more. The in-server module method is an innovation that is not unique to PHP but is a good option for those who want to use it.
Who are these “OO guys” you refer to and what do they have to do with this discussion? I use both in different circumstances, but OO/procedural programming has nothing–zilch–zip–nada to do with this. I’m talking about an execution model, basically–one that is different from the current one. It has nothing to do with one’s choice to use OO or procedural programming.
Interesting. I don’t lump together languages and the systems they exist in. I use PHP because of language features. I use the Apache module because of execution features. Together I end up with a nice script that performs well. I’m merely trying to find a way to write my script in a different execution model.
I wrote the first thing (I think), but I did not write the second. In any case, the opinion that PHP is “more fun than writing in a compiled language” is a reason, however subjective, some people use PHP instead of CGI in C, for example.
No, this does not really solve the problem. It’s a workaround, sure, but it’s not elegant, IMO.
There is no “PHP way” to do anything, other than to write PHP. To contrast with Java, I could write a web application in Java as CGI or as a servlet. The decision has nothing to do with the language but with the execution model.
Sure there’s a “PHP way” to do things. And it’s doing thats that PHP is capable of, or capable of being extended to do. But just because PHP is capable of something, doesn’t mean it’s the way it should be done.
In my opinion PHP is a tool, just like Java is a tool, .NET is a tool, PERL is a tool, etc. The true strength of any programmer is knowing when to use what tool. Trying to shoe-horn PHP into an execution model (as you put it) that it was never designed to handle, is not using the tools effectively. If object persistence and “compile once” are must-have features for your applications, then choose the tool that is designed to solve the problem (ie Java or .NET).
I really need to figure out how to get this board to email when there are posts to this thread.
Yes, but I’m speaking within the context of only one application. However, I see your point. Only one connection could easily become swamped.
But let’s also remember that if the queries are that intensive and the server is poorly tuned, then every new connection will be affected as well. The present paradigm isn’t exempt from this.
For everybody:
My thrust is that we should be able to get away from the ‘connect-query-dis-connect’ routine that many PHP applications use now. So if that means a php application server should itself maintain a connection pool (I clearly wasnt thinking here) to overcome the issues some of you spoke of, then great, as long as it’s transparent to the developer or the executing script. In other words, from the veiw of the executing script or request, there is still just ‘a connection’.
You just subscribe to the therad (under “Thread Tools” top of the thread on the right).
Anyway. Isn’t the easiest way to do a servlet engine just to have a servlet server running with PHP on port 12345 and then use an iframe to pass a file to it? I could scrap something like that together, though I don’t see the purpose.
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.
