Re: Function caching...

> - PHP can either run speedy, as a module, within the context of > the web server, or run with appropriate user rights, when used > as a CGI with suexec or other hacks. > > An application server would enable PHP code to run speedy, > with approproate user rights and WITH NO SUID MAGIC AT ALL. > > Look at safe_mode. It is an abomination. It does duplicate > functionality that should be and actually is in the operating > systems, and it fails in doing this. safe_mode isn't. It fails > systematically, because it requires properly written code to > function correctly, and PHP cannot change the code of all > external libraries incorporated into the PHP proper. Some of > them come .o only (like Oracle). > > An application server will fix this problem and make safe_mode > obsolete, making the code simpler and more secure at the same > time. Properly fixed by the per-virtualhost user/group functionality in Apache 2.0 > - PHP cannot make proper use of a limited number of database > connections or other scarce ressources, because it is forced > to use the web server process model. Apache will open > MaxClients times (user, pass, host) tuples many MySQL > pconnects worst case. > > A threaded application server could preopen a configureable > number of database connections, mark the "useable" or "busy" > and share them among the threads of this particular appserver > instance. This will not only greatly reduce the absolute > number of connections, but make them better controllable > as well. > > Same goes will all other ressources as well. Again, the threaded Apache 2.0 with a resource pool mechanism on a per-process basis and then shared across all PHP threads is a solution here as well. > - PHP currently cannot keep alive variables in a session. > Instead it archives some variables, and revives them in > the next call to a page in the same session. This utterly > fails to handle all kind of entities having external state, > like about any resource variable. Again, the architecture of Apache 2.0 can address this. > PHP currently cannot handle properly large networks of > interconnected variables in sessions, since this consumes > much setup time at the beginning of each page. Also, PHP > has problems handling references properly in serialization. > > An application server does not have such problems, as it > does not need to archive things in the first place. It can > easily keep networks of objects around between calls, and > it can keep ressources alive between calls, barring network > timeouts on inactive sockets and the like. Apache 2.0 > I don't want a module running in the context of each webserver > process, duplicating code, database handles, and running under > the wrong user id. I want my own application context, > independent from the webserver and I want my application threads > to transparently share ressources. I am in no way talking about > mod_perl at all. I am talking more along the lines of WebObjects > and other application servers. I do not agree with you that PHP needs to become an application server like this. It should be friendly to frameworks such as Apache 2.0 that can run PHP in such a manner, and if there are other such threaded servers that can provide the persistency handling it should be friendly to those as well. -Rasmus