What Object cache does is stores metadata about SharePoint Server objects (like SPWeb, SPSite, SPList, etc.) on the WFEs. When a page is rendered, if there is data that needs to be retrieved through these objects, the SQL Server will not be hit. Features of SharePoint that uses Object cache are publishing, content query web part, navigation, ...
After banging my head around for some days, the problem was solved by flushing the blob cache.
This is the command I used on the Front end server
$webApp = Get-SPWebApplication "<WebApplicationURL>"
Write-Host "Flushed the BLOB cache for:" $webApp
You should create a big array that you'll then store into the sessionStorage. And your code is not really clear.... based on what you asked I rewrote it:
// we suppose that "index" is the "Title" we are looking for
var index = "My Title";
// get the data from sessionStorage
var list = sessionStorage.getItem('PrivacyStatementsList');
There are various ways:
// Stop Caching in IE
// Stop Caching in Firefox
or you could use the @Output property:
Here you can find all ...
Object cache - metadata, WP queries of external sources, search boxes, quick launch, breadcrumb
Default is on
Configurable through GUI or web.config per each SC
BLOB cache - binary large objects like images or CSS files, stored on WFE disks
Default is off
Configurable through GUI or web.config
Page (output) cache - for whole pages to load them faster ...
SharePoint Foundation does not support output caching. You have to rely on ASP.NET Cache objects in your code.
Infact BLOB cache, page output, and object cache are not available in SharePoint foundation. Page output and object cache require that you activate the ‘SharePoint Server Publishing’ feature located in the site features of your web site, so these ...
Ok I have finally found the root cause for this issue.
I believe this is a bug relating to either Windows Server 2019, SharePoint Server 2019, or a combination of the both.
Basically, the application pool accounts do not have sufficient permissions to create BlobCache folders in a vanilla install of SP2019 (specifically on Server 2019).
There are 2 key ...
IIS 7 Output caching! I'd enabled this a while ago to try and improve performance on the public side of the SharePoint side - but apparently the only noticeable effect was that the system pages were cached. Oh well, having turned it off my group memberships are now displaying properly. Lesson learned.
I encountered this same problem in SharePoint 2016, and was finally able to resolve it by configuring output cache profiles.
Output Cache Profiles are applied at both the site collection level (by clicking the Site collection output cache link under Site Collection Administration) and the site level (by clicking Site output cache under Site Administration).
If they are 5 different apps from 5 different developers and each is using its own local copy of Jquery then there is nothing you can do. On the other hand, if you are the developer of those 5 apps just use put all common files on a central server and reference the files from there. Browser caching works based on the domain where the file is pulled from.
You can use query string for every new JS/CSS files like ?v=GUID to trick the browsers, which definitely will ensure new CSS/JS will be loaded every time you perform a new deploy. Otherwise, there is no clean solution to avoid browsers' behavior.
/Style Library/my_js_file.css?v=<current date>
It looks like you are calling CSSRegistration on a css file that doesn't exist. CSSRegistration is used to ensure that a css file will only be loaded once even if it is referenced multiple times. It can also allow for conditional loading of stylesheets depending on what browser is being used to view the page.
Have a look through any masterpages or page ...
Next time you make changes to your CSS file, create your own rev/version tag where the CSS file is being referenced (probably your Master Page). This way the browser will break the cached CSS and re-retrieve thinking it's a new file.
<link href="/styles/style.css?rev=03_27_2014_v1" type="text/css" rel="stylesheet" />
Here is my interim solution: using HttpContext.Current.Cache.
There is a good helper class here: http://johnnycoder.com/blog/2008/12/10/c-cache-helper-class/.
If I don't get a better solution for this, I'll mark this as the answer.
Can you deliver the data in chunks? Such as an infinite scroll or paging? If that's the case, I'd say just use AJAX and oData to grab more data as it's needed.
Also, how static is the content? Does it change often? If not you could always try browser caching or offline storage.
Simply put, we might need more information before we could better help out :-)
This blog post explains in a verbose, but clear, fashion about how to appropriately configure blob caching for SharePoint. For example:
Failure to specify a max-age attribute in the BlobCache element of the web.config will result in the default value of 86,400 seconds (24 hours) being used. Use of a non-zero max-age attribute will result in the attachment ...
If they have the namespaces you need, go for it.
You've tagged it with '2013', are you using SharePoint 2013? Make sure that the AppFabric Cache cluster you're using is not the one SharePoint 2013 using, make sure it's on a server that's not one of your SharePoint servers and one that you're maintaining on your own. It's unsupported to use the AbbFabric ...
Try setting query.Webs:
query.Webs = "<Webs Scope=\"SiteCollection\" />";
See if that makes a difference.
I also found another site that might help:
Cache misses are mostly likely to happen because of insufficient memory as they all are stored in Ram. If not then mostly cause must do with the Cache configuration. I would suggest to try the different settings specified for the object cache like changing the maxSize directly in the web.config etc. in the article below,
"Cache miss for query Web" may be the answer. You may be looking at the ULS log for the wrong portion. I would look at the ULS log for the first successful run and see if there is not a cache miss for the list that results in a cache dump for the list you are querying.
You may be able to remedy by changing the query from server side to client side. If I ...
Configuring object cache settings
The object cache settings can be configured at the site collection
level in the user interface by a site collection administrator, and is
on by default. The maximum cache size can be configured at the Web
application level on the front-end Web server to place a restriction
on the maximum amount of memory that ...
You should probably consider what kind of cache are you targeting: client-side cache only (try embedding Pragma:no-cache headers in specific pages/controls or even appending random query strings on every request - very bad for performance if you're doing it in the master page) or server-side cache - e.g. for Publishing sites use Caching Profiles. There is ...
Remember you should not cache the SPListItem itself as it contains a link to the SPWeb used to get it and will often require this to be alive. So get the information out of the SPListItem and into some repository objects.
Disclaimer: I've never tried to use this, but it should work.
The SPListItem has a property SPReusableAcl inherited ...
Make sure you do not have the ASP.NET patch KB2638420/MS11-100 installed. This ASP.NET patch will render the page output cache useless. Just uninstall it or install SP2010 April 2012 CU (which fixes this scenario).