Slow caching mechanism on the client

[Sylvain Perron]

We have a use-case which loads by id the same documents many thousand times in a few seconds. We rely on the out-of-the-box ravendb caching. The entites weight a few KBs (min 5, max 250). I notices that the client-side cache only stores the JSON and if the clients gets a 304 it will materialize a new object from the JSON. This seems to be true when objects aren't loaded into the session.

If there a way we can swap the caching strategy the client uses to materialize the objets? We'd really like to reuse the deserialized objets. We now have no other choice than having a third-level cache on top of ravendb (we fetch the server and only get the response code then use our own cache) but it would be nice if there was a configuration to do so more elegantly.

Thanks

[Oren Eini (Ayende Rahien)]

No, it is not possible.

The object that the session is returning is a mutable one.

If you have two concurrent sessions mutating the object, what do you think will happen?

Note that json deserialization is quite fast, so I'm really surprised that this is an issue.

Can you profile this and see what is taking the time?

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sylvain Perron]

Thanks Oren. I am aware the objects are mutable, but the custom cache we are using clones the objects much faster than the JSON deserializer.

I did profile it and it really was the JSON.NET deserialization though I haven't look deeper to see why it was slow

[Oren Eini (Ayende Rahien)]

How big are your objects? Can you share the profiling results?

[Chris Marisic]

On Saturday, August 29, 2015 at 4:30:59 AM UTC-5, Sylvain Perron wrote:

We have a use-case which loads by id the same documents many thousand times in a few seconds.

That sounds like a bad design. Since you outline none of why taking blind stabs in the dark i'd say this sounds like a case for a reverse proxy such as nginx, lighttp, or hardware etc

[Sylvain Perron]

@Chris No it isn't. The use case is a distributed financial computation server using market data stored on raven. Market data doesn't change often (and is *most of the time* immutable) thus why the caching. The problem is that the data is required by potentially many hundred functions running at the same time and we need the most recent market data.

@Oren Just saw that 99% of the time is spent deserializing a 690KB document which is a matrix with a cardinality of 500,000 which explains why it takes ~150ms to deserialize. I guess we'll have to stick with our custom cache. Do you recommend relying entirely on the changes API to invalidate our cache or should we stick with querying the index with the latest Etag received?

[Oren Eini (Ayende Rahien)]

Well, de-serializing that much would cause some time, if only for the allocations.

You can try creating a custom JsonSerivalizer, override the DeserializeInternal method and hand over a frozen version.

But that is pretty complex.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--

[Federico Lois]

The changes api is what you have to use for the purpose of invalidation. Queries over the index will have more delay.

---

From: Sylvain Perron
Sent: ‎31/‎08/‎2015 22:06
To: RavenDB - 2nd generation document database
Subject: [RavenDB] Re: Slow caching mechanism on the client

--

[Chris Marisic]

On Monday, August 31, 2015 at 8:06:23 PM UTC-5, Sylvain Perron wrote:

@Chris No it isn't.The use case is a distributed financial computation server using market data stored on raven. Market data doesn't change often (and is *most of the time* immutable) thus why the caching. The problem is that the data is required by potentially many hundred functions running at the same time and we need the most recent market data. 

@Oren Just saw that 99% of the time is spent deserializing a 690KB document which is a matrix with a cardinality of 500,000 which explains why it takes ~150ms to deserialize. I guess we'll have to stick with our custom cache. Do you recommend relying entirely on the changes API to invalidate our cache or should we stick with querying the index with the latest Etag received?

Why are you querying (even if its load by id) this data at all? Publish the changes to your services. Have the services hold their copy. 

[Federico Lois]

On a distributed environment you would need another thing like nservicebus. If you don't have it already it is overkill when the changes api would solve the issue.

If you already have a nservicebus like messaging service, you would probably want to use that instead.

---

From: Chris Marisic
Sent: ‎01/‎09/‎2015 12:42

To: RavenDB - 2nd generation document database
Subject: [RavenDB] Re: Slow caching mechanism on the client

--

[Sylvain Perron]

Thanks for the help Federico. We already use NSB so I'll make the invalidation pass through it

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.