Re-populate outputcache after app pool recycled about mvcdonutcaching HOT 7 CLOSED

We can't pre-populate the cache until actual requests are done. The best solution in such environment is to use a distributed cache like redis, AppFabric or else.
Our redis deployment shows nice performance (slower than memory of course).
You could make requests automatically from a script to fill up things too.

So yeah, this solution already exists using little tricks you can achieve what you want.

from mvcdonutcaching.

Thanks for the response - I just thought, given there is a mechanism for using a SQL / distributed cache, there must be a way to load that data back into memory.

Something like this:

1. Request comes in, cache data created and stored in memory & on backup (SQL / dsitributed)
2. Subsequent requests served from memory.
3. Timeouts are handled and evictions impact memory & backup.
4. On app recycle / restart, backup data gets loaded into memory.

Sorry for my ignorance, I really do need to delve into the code more, but I feel like the above seems feasible? Can I ask what I'm missing?

Thanks again for the speedy response!

from mvcdonutcaching.

I have implemented the above using a custom cache provider:

https://gist.github.com/dazbradbury/fe49f77acae71c8479d2

Let me know what you think, but it seems to be working pretty solidly for me!

from mvcdonutcaching.

It's a nice way to implement the things. If it works for you, that's good.

from mvcdonutcaching.

OK cool - I'll finalise my code and update the gist. Maybe you can link to it from the Readme if you think others will find it useful.

On a related note, using the above it's difficult to run code remotely, as you encrypt all data here using the MachineKey:

https://github.com/moonpyk/mvcdonutcaching/blob/master/DevTrends.MvcDonutCaching/Encryptor.cs

I find it interesting any encryption is required, can you explain the reasoning?

I guess the assumption is that donut holes may contain sensitive information, but this seems like additional functionality (the standard outputcache does not do this) - is it safe to bypass this?

from mvcdonutcaching.

It's an heritage from legacy code that I've chosen to keep. Encryption is only used for serialiazing action parameters inside view for later processing. If for some reason, processing doesn't work you could be exposing sensitive internal application details (view names, controller names, etc.)

Again, it's your choice.

from mvcdonutcaching.

Ah OK - good to know.

I'll replace with a different algo that doesn't rely on the machine key.

Thanks again for the reply.
On 19 Mar 2014 13:49, "Clément Bourgeois" [email protected] wrote:

It's an heritage from legacy code that I've chosen to keep. Encryption is
only used for serialiazing action parameters inside view for later
processing. If for some reason, processing doesn't work you could be
exposing sensitive internal application details (view names, controller
names, etc.)

Again, it's your choice.

Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-38052094
.

from mvcdonutcaching.