Re: Function caching...
| From: | Zeev Suraski | Date: | Tue, 12 Dec 2000 15:09:19 +0000 |
| Subject: | Re: Function caching... | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-40973@lists.php.net to get a copy of this message | ||
At 16:53 12/12/2000, Kristian Köhntopp wrote:
Zeev Suraski wrote: When I see Kristian saying that it's fine 'as long as you follow a few simple rules', I know we have an error-prone feature in front of us. For Kristian it may be simple (which I doubt, by the way), but bare in mind that Kristian and you are hardly the average users. Simple things should be simple. Complex things should be possible. That's why PHP has OO and why PHP without OO is simply not acceptable (it would have been okay in 1970).I disagree, it's a matter of opinion. PHP without OO is perfectly acceptable as well. (hint: the most successful commercial scripting language today has no object orientation support).
You said that increasing hardware is not good scalability. That's wrong - this *is* scalability. Scalability means you can get 2x (or close to 2x) performance if you increase the power of your hardware by 2x. And then there is a whole bunch of _really_ _sucky_ _coding_ where increasing hardware won't help you a bit, only better code will. Talk about cubic solutions to logarithmic problems.Most of what you mentioned is a logarithmic problem. It's a cubic solution to cubic problems.
Or simply stupid execution models - today I downsized a newspaper's website from a four processor U-450 to a Netra T1. By using simple script result caching, by the way (3 line change in a perl script - not worth mentioning, except that it brought down the load from over 25 to below 1).I'm not sure what you're trying to prove. Are you trying to prove that what you suggest is the one and only solution? Well, it isn't. Adding hardware is also a solution, especially if it allows you to keep a simple design and not limit yourself in various arbitrary guidelines. Is adding hardware the one and only solution? No, hell no. But it's definitely a solution. IMO, output caching is something that should be avoided if at all possible, and should be reverted to only when there's no other solution. I'd rather upgrade my servers, than switch to a new design that is much more prone to errors. Since using output caching vs. not using output caching is in fact an exponential ratio, then I gather that in some extreme cases it may make sense. However, pushing it as a mainstream good-for-all solution is a *bad thing*. This is the last time I'm going to repeat myself about this. I don't have a problem with seeing an AppServer that behaves the way you described. I really don't. I have a major problem in seeing PHP transform into that AppServer, leaving most users WHO NEED PHP AS IT IS TODAY without a good solution. That's all. Zeev Zeev -- Zeev Suraski <zeev@zend.com> CTO, Zend Technologies Ltd. http://www.zend.com/