I would like to have AWS CloudFront's cache policy handle the caching of an October CMS website instead of October CMS.
Is there a setting in config/cache.php or somewhere for the CMS to bypass the cache?
Thank you.
Depends on which cache you're talking about. If you're talking about route caching, you're looking for cms.urlCacheTtl (https://github.com/octobercms/october/blob/develop/config/cms.php#L172). If you're talking about the parsed page cache you're looking for cms.parsedPageCacheTtl (https://github.com/octobercms/october/blob/develop/config/cms.php#L185). If you're talking about the generated asset cache you just have to set cms.enableAssetCache to false (https://github.com/octobercms/october/blob/develop/config/cms.php#L185).
October doesn't have a cache of fully rendered responses built in by default, so if you have any plugins enabled that implement that just disable them.
Additionally, if you truly wanted to remove every single cache that could be used throughout the entire system you can set the default cache driver to array, but be warned that this is only meant for local development and will cause issues in production (most visibly the Image Resizing functionality built into the core will stop working for resizing new images).
Related
Whenever we purge cache in Cloudflare, we somehow lose the personalization on the Sitecore SXA page. This happens regularly and also on the subpages especially (basically the parent page shows everything correctly). This happens also most of the time inside the footer page design, as it has the personalization activated for certain component inside the footer.
Does anyone knows what the issue can be? Like I said the problem happens whenever we purge the cache inside the Cloudflare.
Also, this always happens inside the en-us language culture, nowhere else.
With no more info is not so easy to understand where to fix this issue.
In your application you should try to disable cache for static assets, you will get load if under real heavy traffic then take care.
This way you will make resources not cached forcing clients to retrieve all data (css, js and so on).
When you will find the bunch of files which makes you hungry (aka the files which cause your issue) you can restore default expire headers.
You can try this if you are not on free plan (if are on free plan min TTL on edge is 2h):
Cloudflare cache rule
set edge cache TTL to 30s
set browser cache TTL to respect existing
headers
set origin cache control to ON
set performance to OFF
I'm setting up the output caching for sitecore with guide provided on SDN.
I've ticked the cacheable and clear on index update and by Data options.
However I noticed that every hard refresh, the full image gets requested i.e. 4 MB.
IS this a an expected behaviour?
Output cache stores generated html instead of executing the process of rendering your component.
It has nothing to do with sending images and caching them in browser cache.
Read How the Sitecore ASP.NET CMS Caches Output JW blog post for more details and see the links in comments.
I am going to assume that by saying "hard refresh" you mean bypassing your browser cache.
What you are seeing is not specific to Sitecore, or any server-side technology. It is your browser that uses caching to keep local copies of images and other "static" resources that it has loaded in the past. This cache is used to speed up page loads and reduce network traffic.
When you perform a hard refresh, the browser will ignore its cache and load all resources from the server. This is why there's a request to your image after a hard refresh.
This is not a normal behaviour.
Sitecore stores all media cache to file system, unlike all other caches, stored in RAM. Media items are stored in in database, so media cache is required to reduce database calls and serve media files faster to end-user. Let's understand Sitecore media cache mechanism.
Please check next link for details: http://sitecoreblog.patelyogesh.in/2014/04/how-sitecore-media-cache-is-works.html
We need our Sitecore web application to process 60-80 web requests per second. We are using Sitecore 7.0. We have tried a 1 Webserver + 1 Database server deployment, but it only processes 20-25 requests per second. Web server queues up all the other requests in the Memory. As we increase the load, memory fills up.(We did all Sitecore performance enhancements recommended). We need 4X performance to reach the goal :).
Will it be possible to achieve this goal by upgrading the existing server, or do we have to add more web servers in production environment.
Note: We are using Lucene indexing as well.
Here are some things you can consider without changing overall architecture of your deployment
CDN to offload media and static asset requests
This leaves your content delivery server available to handle important content queries and display logic.
Example www.cloudflare.com
Configure and use Sitecore's built-in caching
This is from the guide:
Investigation and configuration of the Sitecore Caches is broken down
into multiple tasks. This way each task is more focused and
simplified. The focus is on configuration and tuning of the Sitecore
Database Caches (prefetch, data, and item caches.)
For configuration
of the output rendering caching properties, the customer should be
made aware of both the Sitecore Cache Configuration Reference and the
Sitecore Presentation Component Reference as to how properly enable
and the properties to expire these caches.
Check out the Sitecore Tuning Guide
Find Slow Queries or Controls
It sounds like your application follows Sitecore best practices, but I leave this note in for anyone that might find this answer. Use Sitecore's built-in Debug mode to identify the slowest running controls and sublayouts. Additionally, if you have Analytics set up there is a "Slow Pages" report that might give you some information on where your application is slowing down.
Those things being said, if you're prepared to provision additional servers and set up a load-balanced environment then read on.
Separate Content Delivery and Content Management
To me the first logical step before load-balancing content delivery servers is to separate the content management from the equation. This is pretty easy and the Scaling Guide walks you through getting the HistoryEngine set up to keep those Lucene indexes up to date.
Set up Load Balancer with 2 or more Content Delivery servers
Once you've done the first step this can be as easy as cloning your content delivery server and adding it to your load balancer "pool". There are a couple of things to consider here like: Does your web application allow users to log in? So you'll need to worry about sticky sessions or machine keys. Does your web application use file media instead of blob media? I haven't had to deal with this, but I understand that's another consideration.
Scale your SQL solution
I've seen applications with up to four load balanced content delivery servers and the SQL Server did not have a problem - I think this will be unique to each case depending on a lot of factors: horsepower and tuning of SQL Server, content model of your application, complexity of your queries, caching configuration on content delivery servers, etc. Again, the Scaling Guide covers SQL Mirroring and Failover, so that is going to be your first stop on getting that going.
Finally, I would say contact Sitecore. These guys have probably seen more of what's gone right and what's gone wrong with installations and could get you on the right path. Good luck!
This answer written from a Sitecore developer perspective:
Bottom line: You need to figure out exactly where your performance bottleneck is. That is going to take some digging, but will be very worthwhile. You should definitely be able to serve 60-80 requests/s without any trouble... but of course that makes a lot of assumptions about the nature of your site and the requests.
For my site, I found Sitecore's caching implementation to be sub-par... I created some very simple and aggressive application-specific caches in my app and this made all the difference in the world. For instance, we have 900+ "Partner" items where our sites' advertisements live... and simply putting all these objects in an array in the Application object sped up page requests significantly. Finding an object in a Hashtable indexed by its Item.Name or ID is going to be a lot faster than Sitecore.Context.Database.GetItem("/itempath") or a SelectItems() call (at least, that's my experience). If your architecture and data set will allow this strategy, we've had good experience with it.
Another thing to watch out for is XSLT renderings. Personally, I avoid them completely in favor of ASP.NET UserControls. The XSLT rendering is just slow. As much as 10x slower than a native UserControl rendering the same HTML. So if you have a few of these... replace with some custom code and you'll see a world of difference.
Our website has about 200K images stored in sitecore database now. It runs more slowly than before. Does this large numbers of images stored in database will slow down the whole site?
If yes, how can I improve our image storage?
Thanks very much, our sitecore version is 6.2.
Have you considered setting up a CDN for your static assets? That would reduce load on your site and should speed it up.
Otherwise you might look at optimising the databases. Have a look at the Sitecore Optimisation Guide http://sdn.sitecore.net/upload/sitecore6/64/cms_tuning_guide_sc60-64-a4.pdf
In general, it depends on whether front-end or back-end is slow.
If you experience issues even when the site is not loaded with huge number of requests - then you should probably upgrade hardware.
If it's caused by high website load - there are two rather simple options:
1) Use dedicated image server for Sitecore http://pentialized.dk/2011/01/02/dedicated-image-server-in-sitecore-part-2/
2) Integrate Media Library with CDN, CloudFront is really simple and powerfull, see the example here: http://herskind.co.uk/blog/2012/04/using-cloudfront-for-sitecore-media-content
I have an app which has a search feature. This feature looks up the search term in a giant object (dictionary) that I cache for 24 hours. The object is about 50,000 keys and weighs roughly 10MB.
When I profile the memory usage on my hosting, I notice that after a few queries, the memory usage goes from around 50MB to over 450MB, prompting my hosting provider to kill the app.
So I'm wondering what is going on here. Specifically, how does the cache utilize the memory on each request and what can I do to fix this?
Django FileBasedCache is known for having performance issues. You can get a big picture on the following links:
A smarter filebasedcache for Django
Bug: File based cache not very efficient with large amounts of cached files
Bug was set as wont fix arguing:
I'm going to wontfix, on the grounds that the filesystem cache is intended as an easy way to test caching, not as a serious caching
strategy. The default cache size and the cull strategy implemented by
the file cache should make that obvious.
Consider using a KVS like Memcache or Redis as a caching strategy because they both support expiry. Also, consider a dedicated search like ElasticSearch if more anticipated features will be search-related.
Tools are howtos are available:
Installing memcached for a django project
http://code.google.com/p/memcached/wiki/NewStart
http://redis.io/commands/expire
https://github.com/bartTC/django-memcache-status
http://www.elasticsearch.org/guide/reference/index-modules/cache.html