DevForce 2010: Memory Utilisation

Print Page | Close Window

Memory Utilisation

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1898
Printed Date: 21-Apr-2026 at 12:19pm

Topic: Memory Utilisation

Posted By: agrogers
Subject: Memory Utilisation
Date Posted: 15-Jun-2010 at 11:31pm

Hi

We have started analysing our application memory usage and it seems to be using more than we expected. The Model.dll is 5.1Mb and is made up of 338 tables. Initialising the PersistenceManager consumes about 30Mb. Data loaded into memory consumes about 8 times the memory the same amount of data consumes in a Jet DB. This means that the application can quickly grow to hundreds of MB ... which doesnt seem good.

Is this normal for a Devforce app? What are the implications of a Devforce app growing to hundreds of MBs? And is there some documentation we should be following on the best practices with respect to memory management.

Thanks
Andrew

Replies:

Posted By: ting
Date Posted: 17-Jun-2010 at 9:31pm

Hi, those are good questions. The DevForce in memory cache isn't designed to store an entire database, but with the typical size of database objects, you should be able to work with hundreds of thousands of objects on a modern machine with a few gigs of ram. If you have tables with large binary data, there are some strategies to deal with this (e.g. leave them unmapped and fetch them on demand).

If you are consuming a large amount of memory, then you can remove the objects from the cache after a particular workflow is done. (Use EntityManager.RemoveEntities(), also EntityManager.FindEntityGraph() is handy for this). If you know you won't be needing a query again soon, you can also issue it with a QueryStrategy of DataSourceOnly and this will prevent DevForce from caching additional objects needed to reperform the query in memory (This is probably why you are measuring an 8x expansion. There are likely more objects cached in memory than you realize. We also store the original state of the object so you can perform an undo back to it's original state.)

DevForce also works well with multiple databases, so you if you need to work with massive data sets on the client, you can save to a local database like SQL Server Express.

Is there a particular scenario you've got that would require special treatment?

Posted By: agrogers
Date Posted: 17-Jun-2010 at 11:29pm

Thanks for your response Ting. We are trying to determine what is 'normal' to determine whether or not what we have is normal. Of course 'normal' is not easily defined! A few general thoughts from from what you have said.

1. I thought removing objects from the cache was bad as it can compromise referential integrity. Either we empty the cache entirely or we don't remove anything. Is that correct?

2. Is it possible for you to give me a guide on what memory consumption you would be happy with in a well designed DevForce app? 10s of MBs? 100MBs? GBs?

3. Is there a point where Devforce starts to perform poorly because the cache has got too large?

Thanks
Andrew

Posted By: ting
Date Posted: 18-Jun-2010 at 12:44pm

1. Removing objects from cache will not cause a constraint violation of referential integrity. However, it might be odd if you remove only a few of the LineItems from an Order, but leave the rest. That's why EntityManager.FindEntityGraph() is a useful method in this context. Removing objects from cache also clears the query cache (different from the object cache), so you may notice a few additional trips to the database afterwards. Therefore, I would recommend that you evict objects from the cache at a coarse level in the application, and not perform this overly frequently.

2,3. A few hundred megabytes should be no problem. If you have millions of objects in memory, the in-memory LINQ queries may start to slow down. Otherwise, the concerns would be the same as with any other application - primarily paging memory to disk. If it gets this large, I would consider using a local database as the cache.

Posted By: agrogers
Date Posted: 22-Jun-2010 at 10:05pm

Thanks Ting

1. >>> so you may notice a few additional trips to the database afterwards
I thought that when the query cache was cleared DevForce assumed that no objects were in the entity cache and so calls were *always* satisfied from the database. Pg 240 of the Dev Guide says: "Unfortunately, removing those entities clears the entire query cache. The PersistenceManager will satisfy future queries from the database until it has rebuild its query cache.". So I dont see the point of keeping the Entity Cache when all future requests never use the Entity Cache because of the clearing of the Query Cache.

2,3. Can you point me to further info on 'using a local database as the cache'? I am familiar with writing the cache to a local store for using the application in disconnected mode. But I dont see how that helps reduce memory utilisation. Do you mean that Devforce can use SQL Express (say) as its cache rather than an in memory cache? That would certainly reduce memory utilisation but i can't imagine how that would be possible...

thanks
Andrew

Posted By: ting
Date Posted: 23-Jun-2010 at 7:03pm

1) I'm glad you're reading the Developers Guide ;) The exception to this is if you are looking for an object by primary key (either explicitly, or more commonly through a relational navigation). We are able to check the cache first in this case because this is still a safe operation.

The reason we clear the query cache is complicated, but basically revolves around the fact that we cannot guarantee that the conditions in the cache still satisfy the subquery constraints after objects have been removed. See Query Inversion if you're curious.

2) In the simplest scenario, you just download all the objects you need, save it to the local database, and then clear the in-memory cache. You can then query for whatever objects you need out of the local database, and you can still go back to the main database if you need.

What kind of application are you writing where this is a concern? Unless you have multimedia data or offline search requirements, it would take a user quite a long time to perform enough workflows to get that much data.

Posted By: agrogers
Date Posted: 24-Jun-2010 at 6:33am

1) Ah, yes Ting. It had been a while since i had read just how the CacheThenDataSource query method works. So you are right in that any requests for objects based on primary key will find them in the cache. That should be a lot of them.

2) I think what you are saying is: 1) grab the objects you think you might need 2) write them to a local store 3) direct all queries to the local data store by changing the query strategy to datasource only. Is that close?

We are developing a school administration database. So there is not a lot of media data. Analysing the queries going to the server more seems to suggest that the query inversion is grabbing stuff we weren't expecting. So we are working through the implications of that now.

thanks
Andrew

Posted By: ting
Date Posted: 01-Jul-2010 at 1:41pm

I wouldn't necessarily make all queries to the local datastore as datasource only. (This will turn off query inversion, but will still cache the entities returned by the query). I would consider clearing out unneeded entities after a workflow or periodically clearing the cache. If you have isolated workflows, one technique than can be handy is to create a separate EntityManager as a sandbox for that workflow. Import whatever entities you need into it, and then throw it away when you're done. This might get you the best performance/memory tradeoff and can help minimize any bookkeeping code.

Print Page | Close Window