This module extends the Varnish module to purge caches of multiple configured base urls.

## Installation
You need to have the Varnish module installed and enabled.

Once you have Varnish working, to use the module you need to do the following:

Enable the module.
Configure the following variables in settings.php file:

Cacheable CSRF protection

Provides an alternative CSRF protection mechanism for Drupal forms, that depends on JavaScript but allows form HTML to be cached in reverse proxies or CDNs.

It also provides an alternative AJAX form submission mechanism which partly solves AJAX forms writing to form cache on every request which has been fixed in Drupal core 8.x.


Prerender, prefetch, dns-prefetch, helper with visitor flow knowledge provided by Google Analytics.

Panels PHP

The Panels PHP provides a panels pane to improve php input experience and performance for panels.

Just enable and go to add content in panels, you will see and enjoy!


Views Field Join Node Revision

This module adds a condition on the node-id as well as the revision-id when joining the node_revision table with the field_* tables. This can make MySQL utilize the compound primary key better.

It might be better to actually make a patch for the Views module instead, but at this point I'm not sure about all the implications that adding the join handler will cause.

Independent Cache (with delayed removal)

What is?
A delayed to clear cache.
An implementation of a cache to be used selectively on Views and Blocks so that they don't get cleared when a Drupal Clear cache is issued or other triggers that would other wise immediate clear the cache and cause a regeneration of the data/content.
The concept behind this cache is that by choosing which views and/or blocks are too heavy to generate (causing the server performance to go down on high traffic sites), allowing them to be generated some time after and not at the same time, doing a redistribution of the work during time.

At some events the cache is cleared and therefore all data needs to be generated and processed again, if this happens for some heavy processes on a high traffic site you may end up running several heavy process at the same time plus all the small process and you may bring the server down temporary, similar to what happens with a DOS attack.
If we can delay the most heavy parts to be processed after all other caches are ready and meanwhile we use "old" caches for those parts until we get those processed again it would allow to redistribute the processing during time and not all at the same time.



Subscribe with RSS Subscribe to RSS - Performance and Scalability