We installed node queue module on pressflow 6 + varnish. For clearing the varnish cache for node queues, we developed rules using rules,cache action modules. But the issue comes, whenever we update the content,it is reflecting for logged in users, but it is not reflecting for anonymous users.Could you please suggest us for how to clear varnish cache with rules or any custom code?
Thanks,
Raghu
in the CLI:
ban.url .
This will clear the cache.
Related
I have an issue with typo3 and caching.
We have done the following setup:
1 Nginx load balancer (ip_hash i.e sticky sessions)
2 TYPO3 web instances
1 redis cache shared by both typo3 instances
The issue is that when the first web servers serves a given page, it gets cached. As long as the same web server is serving that page, the cached version gets returned.
As soon as the page request is served by the other web served, the full cache get reloaded.
I noticed that additional items are added to the cache although the page content has not changed.
Is there anything I could check to avoid these unnecessary cache reloads?
There are some considerations before scaling TYPO3 horizontally: https://stackoverflow.com/a/63594837/2819581
Basically, database/caches and some directories all carry state which is not independent of each other.
I have built a new site for a customer and taken over managing their domain and using a new hosting. The previous site and hosting have been completely taken down.
I am running into a major issue that I am not sure how to fix. The previous developer used a service worker to cache and load the previous site. The problem is that users that had previous visited the site keep seeing the old one since it is all loading from a cache. This old site no longer even exists so I have no way of adding any javascript to remove the service worker from their browser unless they hit the new site.
Has anyone ever had this issue and know of a way to resolve it? Note, asking the users to delete the service worker from their browser won't work.
You can use cache busting to achieve the outcome. As per Keycdn
Cache busting solves the browser caching issue by using a unique file
version identifier to tell the browser that a new version of the file
is available. Therefore the browser doesn’t retrieve the old file from
cache but rather makes a request to the origin server for the new
file.
In case you want to update the service worker itself, you should know, for a service worker an update is triggered if any of the following happens:
A navigation to an in-scope page.
A functional events such as push and sync, unless there's been an update
check within the previous 24 hours.
Calling .register() only if the service worker URL has changed. However, you should avoid changing the worker URL.
Updating the service worker
Maybe using the clear-site-data header would be the most thorough solution.
I'm considering to use Varnish as a caching solution for our infrastructure and I would like to ask if there a mechanism inside Varnish, which solves cache slamming / stampeding problem?
Since Varnish 4.0, You can serve stale while revalidate using the grace time (https://info.varnish-software.com/blog/grace-varnish-4-stale-while-revalidate-semantics-varnish ).
Varnish will asynchronously fetch the response from the backend and serve the stale cached content if it is in its grace period.
I am developing a web page where server has to send a cache name to the client, when ever a new cache is created using ConfigurableCacheFactory.ensureCache() or CacheService.ensureCache() by any other extend clients.
Will there be any event that I can listen at the server end, which will be triggered after creating a coherence cache in cluster, such that I can listen to that event and send the newly created cache name to the client ? Any help would be appreciated. Thank you!!!
Normally, I would start by looking at the LiveEvents feature. For example:
http://www.slideshare.net/OracleCoherence/coherence-live-events
http://docs.oracle.com/middleware/1213/coherence/develop-applications/api_live_events.htm#COHDG5611
http://docs.oracle.com/middleware/1213/coherence/tutorial/uem.htm#COHTU950
https://www.youtube.com/watch?v=ebEBv817Jn0
However, I don't think that there is an event for a cache being created. You can certainly detect when a cache is created, but it is a relatively low-level capability, e.g. implementing (over-riding) a ConfigurableCacheFactory, or a BackingMapManager, or a Backing Map. All are very advanced. Perhaps there is a simpler approach that you could consider? Like just putting that new cache name somewhere in a registry or a thread-local variable?
today I dealt with a task to load a module's configuration into running Magento site under heavy load. I copied config.xml file of new module and everything to fix some issue.
Our Magento runs with memcached caching backend.
To have a module running I had to clear cache completly and that had an impack on performance of the site, we had 500 of concurent users . So I'm looking for solution how to deploy changes in of configuration without clearing cache.
Is there any?
Thanks for any thoughts and ideas.
Jaro.
Here is a method of updating the config cache rather than clearing it, thus avoiding race-conditions.
https://gist.github.com/2715268
You don't have to clear the entire cache to load a module's configuration. You can install the module by using the Flush Magento Cache* option. Eventually you'll need to clear the cache to see your front-end changes if any were made. The best thing to do to minimize performance impact is to clear it during off-peak or low-usage times.
*edited - Thanks Fiasco Labs
it's probably best practice to put the system in maintenance mode, make sure all admin sessions are logged out, check that everyone's out and then manually delete var/cache/mage--? folders. You then log back in on one admin session, let it run till you see an admin session has started, log back out and then back into Admin to start checking the site for full function of the freshly installed module.
You will always have to flush cache when installing a module or changing its configurations. This is necessary to force rereading of configurations, to empty out incompatible opcode and force Magento to re-read application code and templates for the changes you have just made.
Yes, it has a momentary impact on your site's performance, but can cause some really interesting issues if you don't.
I've had situations where using the button in Admin wasn't enough, for module installs, it's probably best practice to put the system in maintenance mode, make sure all admin sessions are logged out, check that everyone's out and then manually delete var/cache/mage--? folders. You then log back in on one admin session, let it run till you see an admin session has started, log back out and then back into Admin to start checking the site for full function of the freshly installed module.
This is of course overkill for simple config changes where a cache flush is sufficient.
More info on clearing the cache in Magento