We are using Voyage to store a lot of data to a MongoDB.
Currently the problem is, that Voyage is caching all the objects that are saved to the DB. And whenever the cache approaches the maximum of its size, it's becoming very slow.
Sure, we could just increase the maximum size of the cache, but the class description of VOMongoCache says:
Main purpose is not optimization but prevent duplicated objects (when they should be the same)
Because we are saving only new generated objects, we don't need these caches anyway.
So we want to completely disable the caching. Currently we just use this workaround to disable caching:
VOMongoCache>>
at: anOID put: anObject
self compactIfNeeded.
self mutex
critical: [ "objects at: anOID put: anObject" ].
We just commented out the part to add the object to the cache.
Is there any better solution to disable caching completely?
Thanks in advance!
Voyage is a an object graph serializer. Therefor the cache is absolutely needed. Your use case is probably not a prominent one of all that were considered when the design was made. You are just writing objects but from the view point of the serializer you could read any time and then it should be correct.
Anyway. Maybe it helps to fine tune your application. What Voyage does is that all active objects are hold in the cache. With active I mean that there is a reference to the object from any processing code at the moment. If the objects are not active anymore the garbage collector removes them and at the same time they are nil'ed in the cache. If the cache grows too big a compaction will start removing all the nil'ed entries making space for new objects. If you have one method running that keeps a reference to all the objects you serialize than the cache will grow, it will compact but not free slots. So the compaction is tried again in the next step making the whole thing slow.
The thing you could do is that you process your objects (that have to be written) in a way that you hold a few, serialize them and then they should go out of scope so the cleaning process can manage them. Second I would extend the compactLimit on the cache using
VORepository current cache compactLimit: aNumber
This way the compaction is run less often giving your code and GC more time to resolve the problem in parallel.