Content request caching
Reported by Ben Hood | June 9th, 2011 @ 08:17 AM
The call to request an entity's content gets proxied through the agent without any caching at all. We could consider some kind of caching in the agent that has a configurable expiry. Calls to cached content would either be served from the cache or 304'ed where appropriate.
The expiry time might have to be chosen carefully. Potentially the main use case is to stop the end user clicking a lot in the UI and issuing heavy calls for each click.
The other option is to introduce caching at the participant, which would have less chance of going stale, since the participant has more knowledge of how long it can cache things for.
See also #258 for a ticket relating to the client side handling of this
Comments and changes to this ticket
-
Ben Hood June 9th, 2011 @ 10:19 AM
- Tag set to “caching, performance”
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
A Real Time Differencing Tool.
People watching this ticket
Ben Hood
Tags
Referenced by
-
258
Content viewer latency
When you click through diff list, requests to retrieve th...