[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