[RT] Enhance script caching

[Carsten Ziegeler <cz...@apache.org>]

Hi,

the way the current script cache works is really not optional: it takes
information from the request as the key, namely the extension, the
selectors, the target resource type and the target resource super type.

As recently discussed, we should remove the support of
Resource#getResourceSuperType which makes things much easier including
caching.

But the above way has one major drawback: the cache (key) does not take
into account which scripts are available, it is based on the number of
possible combinations of extension and selectors for urls - which
usually is unlimited. For example, if only an html script exists for a
resource type (no scripts for specific selectors), requesting
foo.a.html, foo.b.html, foo.html result in three different cache entries
all pointing to the same. Which means with extensive use of selectors,
the cache becomes useless and ineffective.

So rather caching the endless combinations, we should cache what is
available: for a resource type we can cache the combination of
extensions and selectors where scripts exist for. This is usually a very
small number. The cache can also know the resource type hierarchy and
then becomes really effective as it can simply traverse the cached
information top to bottom to find the script. With the right data
structures this should really be simple to implement.

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: [RT] Enhance script caching

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Thu, Mar 24, 2016 at 8:39 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ....So rather caching the endless combinations, we should cache what is
> available: for a resource type we can cache the combination of
> extensions and selectors where scripts exist for....

This sounds good to me, and I suppose the registration of new servlets
should have an impact on this cache? As those new servlets can
potentially replace scripts if they provide a more specific match to
the current request.

-Bertrand

Re: [RT] Enhance script caching

[Julian Sedding <js...@gmail.com>]

I fully agree. The script resolver should probably leverage the
resource type hierarchy service you suggested previously.

Regards
Julian

On Thu, Mar 24, 2016 at 8:39 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> the way the current script cache works is really not optional: it takes
> information from the request as the key, namely the extension, the
> selectors, the target resource type and the target resource super type.
>
> As recently discussed, we should remove the support of
> Resource#getResourceSuperType which makes things much easier including
> caching.
>
> But the above way has one major drawback: the cache (key) does not take
> into account which scripts are available, it is based on the number of
> possible combinations of extension and selectors for urls - which
> usually is unlimited. For example, if only an html script exists for a
> resource type (no scripts for specific selectors), requesting
> foo.a.html, foo.b.html, foo.html result in three different cache entries
> all pointing to the same. Which means with extensive use of selectors,
> the cache becomes useless and ineffective.
>
> So rather caching the endless combinations, we should cache what is
> available: for a resource type we can cache the combination of
> extensions and selectors where scripts exist for. This is usually a very
> small number. The cache can also know the resource type hierarchy and
> then becomes really effective as it can simply traverse the cached
> information top to bottom to find the script. With the right data
> structures this should really be simple to implement.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org

RE: [RT] Enhance script caching

[Stefan Seifert <ss...@pro-vision.de>]

sounds good to me.

stefan

>-----Original Message-----
>From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>Sent: Thursday, March 24, 2016 8:39 AM
>To: Sling Developers
>Subject: [RT] Enhance script caching
>
>Hi,
>
>the way the current script cache works is really not optional: it takes
>information from the request as the key, namely the extension, the
>selectors, the target resource type and the target resource super type.
>
>As recently discussed, we should remove the support of
>Resource#getResourceSuperType which makes things much easier including
>caching.
>
>But the above way has one major drawback: the cache (key) does not take
>into account which scripts are available, it is based on the number of
>possible combinations of extension and selectors for urls - which
>usually is unlimited. For example, if only an html script exists for a
>resource type (no scripts for specific selectors), requesting
>foo.a.html, foo.b.html, foo.html result in three different cache entries
>all pointing to the same. Which means with extensive use of selectors,
>the cache becomes useless and ineffective.
>
>So rather caching the endless combinations, we should cache what is
>available: for a resource type we can cache the combination of
>extensions and selectors where scripts exist for. This is usually a very
>small number. The cache can also know the resource type hierarchy and
>then becomes really effective as it can simply traverse the cached
>information top to bottom to find the script. With the right data
>structures this should really be simple to implement.
>
>Regards
>Carsten
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziegeler@apache.org