Thymeleaf Cache Dialect released

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Thymeleaf Cache Dialect released

Antibrumm
Hi all

got a first version ready that supports partial page caching.

The Cache dialect supports three attributes:

    cache:name="name" -> Cache by name
    cache:ttl="60" -> Make cache live 60 sec since creation (no extension on cache hit)
    cache:evict="name" -> Evict cache by name

All attribute values can be an expression.

https://github.com/Antibrumm/thymeleaf-extras-cache-dialect

It's not perfect yet but it does the job quite well i would say:

  a.bs.size() = 1000, b.cs.size() = 3 --> uncached: 1200ms, cached: 150ms
	<ul cache:name="menu_indef_+${a.bs.size()}">
		<li th:text="${a.title}"></li>
		<li th:each="b : ${a.bs}" th:object="${b}">
			<span th:text="*{text}"></span>
			<ul>
				<li th:each="c : ${b.cs}" th:object="${c}">
					<span th:text="*{text}"></span>
				</li>
			</ul>
		</li>
	</ul>

The cache uses currently the FragmentCache of Thymeleaf, which is kind of ok as it's caching a Macro element with the output string of the cached element as it's content.

Also I'm currently missing a declarative eviction strategy for these cache elements, so the cache is living essentialy for ever.

Hope you like it.

Anti
Reply | Threaded
Open this post in threaded view
|

Re: Thymeleaf Cache Dialect released

Emanuel
Administrator
So this cache is for storing the execution result of certain parts of pages so they don't need to be executed again?
Reply | Threaded
Open this post in threaded view
|

Re: Thymeleaf Cache Dialect released

Antibrumm
Exactly.

I haven't found such a possibility in thymeleaf (yet?), so i did something which just matches my needs.

I use it currently in two places:

 - The application menu which is based on user role(s) and active application modules. So i cache it based on the roles and evict the cache on the page submit of module activation (post rendering with a tag containing cache:evict="name").

 - Some "select input" where the content is dynamic but only depending on active entity classes (based on active modules). This here is working as we dont care about the "selected" value at this stage.

The cache:ttl is just an addon and not used yet by myself as i evict the cache explicitly atm.
Reply | Threaded
Open this post in threaded view
|

Re: Thymeleaf Cache Dialect released

danielfernandez
Administrator
Looks good Martin, that's an interesting idea. You are right, Thymeleaf offers nothing similar to this at the moment.

Would you send me a brief description so that I can add it to the ecosystem page? http://www.thymeleaf.org/ecosystem.html

Regards,
Daniel.
Reply | Threaded
Open this post in threaded view
|

Re: Thymeleaf Cache Dialect released

Antibrumm
Something like this?

----
A dialect for Thymeleaf that allows you to do partial page caching.

Some parts of our webpage will not change often during the lifetime of the application or is dependent only on a usersession.
This dialect will cache the resulting output of the element it is declared on and will replace the element on a cache hit.
----

Also: If you wish to include this into thymeleaf itself, please feel free to do so.
Reply | Threaded
Open this post in threaded view
|

Re: Thymeleaf Cache Dialect released

danielfernandez
Administrator
Reply | Threaded
Open this post in threaded view
|

Re: Thymeleaf Cache Dialect released

bpolster
FYI, At Broadleaf Commerce we had a similar need to cache pages.    We were unaware of this dialect.

We thought this concept would make sense as a core concept for includes, substituteBys, etc.  but it was unclear of the best approach.  

We now provide a solution as a custom Broadleaf dialect but would happy to contribute towards a more generalized solution  ...
 
This commit shows how we approached the problem ...
https://github.com/BroadleafCommerce/BroadleafCommerce/pull/761

Key differences in the BLC approach -
--> Replaces substituteBy
--> Adds a cacheKey parameter.  
--> The cacheKey can be further resolved to allow for custom interpretations of the value.   For example, you could say cacheKey="guests,products=1" and write a resolver where that meant something to your application.   By default, the string value is used as the cache key.
--> The BLC solution currently depends on ehCache.

From a pure numbers point of view, one of our pages (http://demo.broadleafcommerce.com/hot_sauces) was performing at about 13 pps.    After mostly caching the page, we see a throughput of 400 pps and 30ms response times.

I would be happy to help work towards something more compatible with core and/or this dialect but the direct/best path to do so is not clear to me.


Reply | Threaded
Open this post in threaded view
|

Re: Thymeleaf Cache Dialect released

Antibrumm
Hi

I took a look at your implementation and I think we are going in a very similar direction. I'm always happy to accept inputs to improve implementations such as the cache dialect, so we can surely discuss about any ideas you might have.

I think that my implementation has the advantage that it is less "intrusive" than your approach of a specific tag, as you can apply the cache key on any element in the DOM tree to activate caching.

As far as i can tell it should also work for your purpose with the cacheKey attribute.
Have you already tried to replace your cacheKey attribute with the cache dialect and compared the results?