[ZODB-Dev] [Enhancement Proposal] Memory size limited Cache
Dieter Maurer
dieter at handshake.de
Fri Oct 6 16:55:40 EDT 2006
Jim Fulton wrote at 2006-10-6 16:18 -0400:
>Dieter Maurer wrote:
>...
>>> The only benefit of multiple threads is that it is somewhat
>>> less likely that expensive requests will block inexpensive ones.
>>
>> Multiple threads can share resources such as main memory and
>> a common cache (proposed by the original poster).
>
>If there is only one thread, the resources are completely
>shared among all threads.
Sure, but if I have instead on n threads n processes,
then the n threads share the resources but the n processes
have each a copy of them: memory consumption with grow by
roughly a factor of "n" (not completely, because some
resources (such as the code segment) can even be shared among
processes and not all processes may need all of the resources).
> ...
>> While this does not give more throughput, it uses memory more
>> efficiently.
>
>No, it doesn't.
>
>Even if *all* objects in the cache are shared, using multiple
>threads doesn't reduce memory. It just doesn't use more memory.
>Of course, if any objects can't me shared, then using
>multiple threads will surely use more memory, not less.
Maybe, we need to look at a concrete example:
Our application roughly has the following memory requirements:
5 MB code (Python interpreter, shared libraries)
35 MB data (e.g. Python bytecode)
20 MB ZODB caches
20 MB module level caches
-----
80 MB
Currently, we use 4 threads (the normal Zope configuration).
If we use instead 4 processes, then we will get the following rough
memory requirements:
5 MB code (shared amoung all processes)
4 * 35 MB data (the data might be shared, but the OS does not know it)
20 MB ZODB caches
4 * 20 MB module level caches
-----
245 MB
>...
>
>> We abused Zope a bit and have build a desktop application with it.
>>
>> One of the main critiques of our customers is too high memory
>> consumption. Many have computers with 256 MB memory and
>> they do not like at all that our application uses roughly a third
>> of it...
>>
>> They would even less like it when there were several processes
>> with each of them taking about 60 MB (many of our caches
>> are on module level and are shared indeed).
>
>OK, so, for a desktop application responsiveness is a big
>issue. There the benefit of multiple threads is that you can
>keep the UI responsive while you do background processing
>in other threads. The benefit is responsiveness.
I am comparing multiple threads with the multiple processes szenario
you have proposed. Then threads do not give more responsiveness.
>So, in an application like this where there *is* a benefit
>to having multiple threads *and* you have a lot of read-only
>data, then I agree that there would be a benefit to sharing
>the data. Of course, then you have to deal with thread-safety
>issues that you don't normally have in a ZODB application.
Thread-safety is not an issue for read-only data.
--
Dieter
More information about the ZODB-Dev
mailing list