Re: Function caching...
| From: | Kristian Köhntopp | Date: | Mon, 11 Dec 2000 17:20:46 +0000 |
| Subject: | Re: Function caching... | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-40869@lists.php.net to get a copy of this message | ||
Zeev Suraski wrote:
> I didn't say that it will require big changes. Much like the fact that I
> can plug the Zend Engine in MySQL doesn't mean that users should start
> serving their Web pages off stored procedures, the fact you can create a
> Zend engine based application server doesn't mean that PHP should *become*
> that application server. It doesn't matter if you'll have to change 2
> lines, 500 lines or 10K lines... What matters is what you end up with.
I do not know what I will actually end up with.
What I do _want_ to end up is quite simple, though.
I want to end up with is a long running process running
under a user id different from the web server, listing on an ONC RPC
port or a similar communication channel for requests, having a pool
of threads and a pool of database connections governed by a ressource
management mechanism similar to what Apache offers for number of
worker threads (StartServers, MinSpareServers, MaxSpareServers,
MaxClients like limits for threads and DB connections). I want that
thing to keep compiled bytecode in memory, r/o and shared between the
threads, if possible and I want to limit that amount of memory in
a LRU style fashion, so that unused bytecode is being dropped in
low memory situation, but compiles are saved when there is enough
memory.
I want that thing to be able to execute unmodified PHP scripts,
if possible, dropping ressources at script end as before, but
keeping bytecode around. I want that thing to keep session variables
actively, no serialization needed, and to work with pooled ressources
such as database connections in a sane manner. That way, references
and ressources will not be a problem as session variables.
And I believe that this will be slightly larger than your average
sapi interface, but not so much that it would not fit into a sapi/
directory in your normal PHP distribution, including the stub program
as a CGI and a module version. I would not call this breaking the
language, in fact the average user not using session_*() functions
probably will not even notice the difference besides faster execution
times.
Now please tell me where the hole is in my reasoning.
Kristian
--
Kristian Köhntopp, NetUSE AG Siemenswall, D-24107 Kiel
Tel: +49 431 386 436 00, Fax: +49 431 386 435 99
Using PHP3? See our web development library at http://phplib.netuse.de/