![]() ![]() You may be able to with a Gateway cache, or with a private cache (aka, your client can figure out caching based on your expiration headers). Requests behind authentication and/or SSL are usually not cached.Using the Cache-Control header to set a response to 'public' will allow Proxy and Gateway caches to cache your site content.If you have a Gateway cache such as Varnish, you can potentially cache responses to end points per user A gateway cache gives you a lot of cache control since its part of your stack.This is good for APIs with a lot of writes (updates) to resources.ĭone with Expires, Cache-Control, Date and related headers, expiration caching can aid in caching a response for the next user (or even for one specific user) on subsequent page loads, saving your server(s) from traffic load Concurrency Control - in a POST or, more likely, PUT request, a server can check if the resource being updated was changed since the requester last checked (solves the Lost Update Problem).This is good for mobile APIs where the bandwidth of re-sending a message body can be saved via conditional requests. Conditional GET requests - a server can tell the request 'nothing has changed since you last checked'.Expiration - save round-trips to the origin server - a cache can potentially serve a response directly, saving the origin server from even knowing about the requestĭone with if-* headers ( If-Match, If-Modified-Since, and so forth), validation caching is primarily used for 2 things (most useful for an API, in my opinion).Validation - save bandwidth by not having an origin server reply with a full message body (your origin server returns a header-only response).The HTTP spec defines 2 methods of HTTP caching: This is your web-server - the one that has your application and static assets, such as images, javascript and css files. Note: I'll use the term origin server a lot. Which cache mechanisms you use depends on your use case. Making a response (web page, api-response, etc) cacheable is part of the HTTP cache mechanism. Your browser is a private cache it will cache responses unique to the sites you visit. Private - Private caches are caches that are unique to a specific user.They sit in front of your web-server and act much in the same way of proxy servers - except they are for your application(s) only. Gateway - Similar to in-app caches, Gateway caches live as part of your infrastructure.Because they are employed at a high-level, they can (and do) cache thousands of various websites. Proxy - A proxy cache is a public, shared cache often employed by an ISP or large corporation.They can potentially save requests from ever reaching your server by responding to a request itself. HTTP Caching is mostly done by third-parties. Your code checks your in-app caches and determines if it should use them to retrieve data in order to fulfill the request. It takes action when a request makes its way to your server. It allows you to store objects in memory for quick retrieval. In-app caching lives in your infrastructure and interacts with your application code. HTTP caching - proxy, gateway, and private.In-app caching (APC, Memcache, Redis, other memory stores).colocated cache is really about the load.At a high-level, there are two popular types of caching: Q: Is dedicated caching better for our scenario? how much is left over and whether or not that is of any use to your main application You will need to try this out to see how much ram you get vs. I believe colocated cache is supported at Small instance and higher. Q: We use extra-small web role instances now - do we need to upgrade to small/medium instances?Ī: Yes. The endpoints to co-located cache are strictly internal. Q: If there was a way to update co-located cache from an external app, cache notifications could be used to invalidated all co-located cache nodes, correct?Ī: I don't believe so. Either way, you're implementing your own notification mechanism Alternatively, throw a message onto a queue and have your Webroles monitor that queue and clear the item from cache when they receive a message in the queue. And I would call that endpoint from your external apps (this endpoint can be a service, rest URL, etc). Q: How can the co-located cache be updated from an external app?Ī: I would expose a public endpoint on your Webrole that would clear cache.After doing a bunch of research and guided by Simon's responses in the SO thread he already mentioned, here are my responses: ![]()
0 Comments
Leave a Reply. |