Re: Function caching...

Zeev Suraski wrote: > There are *very* good reasons why it shouldn't happen. It's *extremely* > dangerous, and you have to have a very good idea of what you're doing (for > instance, you mustn't cache any function that depends on SQL or any other > external data source that may change). In many cases even these can be cached, if you take some simple precautions. Replacing values _not_ being part of the hash key is what forces a cache invalidation, and by simply including a change indicator you save yourself a manual cache invalidation. > This is the sort of feature that > would be rated as 'prone to problems'. I'm not saying it mustn't exist, > I'm saying it shouldn't be advertised as a good thing to do, because it isn't. It is a central feature of some more tightly integrated systems, like for example the Roxen web server, which has done function output caching, generated image caching and a few other things for more than five years now. My Roxen based websites were featured on /. two or three times now and machine and the web server came through it with straining, but without dying (Dual Pentium-I with 200 MHz, 128 MB RAM, Roxen 2.x and five 2 MBit/sec lines attached to it). The point here is that I did nothing special to this pages, I just coded them. Roxen essentially turned them into static pages where possible, and rode the onslaught gracefully. That's not too bad for a megalomaniac ex-MUSH with delusions of being a web server (The Roxen version of PHPLIB is used in www.real.com's main webserver and performs well, thank you. Place #6 in the worldwide traffic statistics). 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/