Re: Function caching...

Jacob Verhoeks wrote: > The performance problem is not with executing but with the loading of the > code. We are currently developing a application server in php. That will be > loaded only once. The current performance limitations in PHP come from multiple design limitations. You already stated that the repeated compile is slowing down applications. Zend is currently constructing the Zend Cache, which will take care of that, but I believe that this is only a cure of a symptom and does not address the real problem. Another problem is the setup time for large data structures, for example a large network of objects representing an entity relationship model by proxy or similar abstraction layers. If this network of objects is rebuilt from scratch in each instantation of your script, it will take significant amounts of time. Even if you just revive the dead object network from serialization this will slow you down. The third problem is the indivisible user rights if you are running as a part of the web server, as Apache modules do. You always act as wwwrun. On the other hand, you are running in a different Apache module each time you are being called, making it impossible for you to reuse database connections, keeping cursors between calls and the like. That is, the process split of your web application is along the wrong lines. The second and third problem are only cured properly by an application server, that is, a long running, multithreaded, single process with a UID different from the webserver which does run only a single script, but does so across multiple web requests to that script. Indicidentally, such a construct would also get rid of the first problem and make the Zend Cache obsolete, as the code is loaded only once and kept running. I believe a Zend/PHP application server is sorely needed for the future growth of PHP. Some people in #php.de are coding at application servers written in PHP. These beasts communicate with the web server using shared memory. They aren't multithreaded which is why they need to prefork themselves, turning them into memory hogs. A proper native implementation is needed instead. Ulf has a different type of problem, and is using different means to solve it: Ulf has a number of functions returning identical pieced of HTML and results from multiple calls. These functions are long running. He needs a function result and function output cache to take load off his interpreter. The code I wrote and attached to my original mail implements such a function result/output cache (on disk) as a sample implementation in PHP. Using a PHP written function cache makes life difficult, as you have to manually change all function calls to use the cache wrapper. A native implementation would do this transparently once you set a function cacheable. Cacheable functions are idempotent functions, that is, functions that are giving the same result for the same set of input parameters. Additionally, these functions need to be side-effect free, that is, they must not use hidden parameters via global, external files or database access. Some people may set uncachable functions to cacheable although they know that this is making false assumptions, if the side-parameters (database content for example) changes seldom, or is synchronized with parameter changes. To enable such uses, you need cache flushing functions, and probably a variable timeout on cached values. Cached output and results need to go to persistent storage, and that storage should be user implementable as with the current session functions. This pretty much describes the needed interface. It is independent of the changes needed for an application server, and the benefits are realized independently from an application server. Both projects are urgent and worthwhile. 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/