OK, I'll try to summarize.
> Because it will hurt performance, and gaining performance usually costs
> much more that gaining memory (compare expense for doubling memory and
> doubling performance). Most people in most cases are willing to trade
> memory for performance - that's why caching exists.
1. I agree, but I agree also with Brian (see
http://marc.theaimsgroup.com/?l=php-dev&m=98081424122248&w=2 ).
2. From our tests we cannot say, that CPU performance is considerably
better when cache is enabled (on RH6.2 it is less than 10%). I've
already written about it. When there are x servers to upgrade with
extra RAM memory - this COSTS (especially in Poland ;).
3. "We are free to turn it off" - Yes, but now there are no
simply means to do that. So "we demand" some option in
.configure script, of course cache should be on by default.
Now we can use solution described in
http://marc.theaimsgroup.com/?l=php-dev&m=98053283403331&w=2
It has been tested much, but no warranty !
4.
>And, BTW, you can control it - see MAX_ constants at zend_alloc.h
As I CLEARLY (as I think ...) described in
http://marc.theaimsgroup.com/?l=php-dev&m=98080647502573&w=2
the mechanism of memory "deadlocks" is not based on the cache size
(it is small in fact), but in order of memory operations (problem
appears even when the size is set to 1 !). We've tested some
very simple fixes (turn off ZEND_FAST_CACHE and for example
force the shutdown_memory_manager always to clean the cache, not
only when "clean" flag is set. It needs some small modification
in for loop in order to reinitialize cache globals) and the problem
has dissapeared (almost, but I'll say about it later in 5).
The CPU performance lowers down only a little bit.
5. We've found out that not only the php memory caches are responsible
for described effect. When we use oci8 module - the effect comes back
(but in smaller size), because there's independent memory management
in that module (and in oracle libraries). We are working on it.
I hope this discussion shall result in most effective and
flexible solutions.
Filip Sielimowicz
[EMAIL PROTECTED]
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
