You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Thomas Heigl <th...@umschalt.com> on 2013/06/17 15:21:41 UTC
Server side caching of generated resources
Hi all,
I was wondering if Wicket has a built-in mechanism for caching the
generated byte[] of package resources. I use concatenated resource bundles
that are compressed using the YUI CSS/JS compressors.
Using the default settings, compression is performed for every request that
does not have it in the client cache. Since this compression is a very
complex operation I'd like to perform it only once.
Cheers,
Thomas
Re: Server side caching of generated resources
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
At the moment there is no caching of the content.
The only library that does such kind of caching is
wicket-bootstrap:bootstrap-less (
https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/bootstrap-less/src/main/java/de/agilecoders/wicket/less
)
On Mon, Jun 17, 2013 at 5:06 PM, Thomas Heigl <th...@umschalt.com> wrote:
> Hi Michael,
>
> This caches only the resource version, e.g. message digest, but not the
> actual contents of the resouce.
>
> Kind regards,
>
> Thomas
>
>
> On Mon, Jun 17, 2013 at 4:02 PM, Michael Haitz <michael.haitz@1und1.de
> >wrote:
>
> > Hi Thomas,
> >
> > it depends on your deployment mode:
> >
> > if (application.usesDevelopmentConfig())
> > {
> > // development mode:
> > // use last-modified timestamp of packaged resource for resource
> > caching
> > // cache the version information for the lifetime of the current
> > http request
> > resourceVersion = new RequestCycleCachedResourceVersion(
> > new LastModifiedResourceVersion());
> > }
> > else
> > {
> > // deployment mode:
> > // use message digest over resource content for resource caching
> > // cache the version information for the lifetime of the
> > application
> > resourceVersion = new CachingResourceVersion(new
> > MessageDigestResourceVersion());
> > }
> >
> > best,
> > Michael
> >
> >
> > Am 17.06.2013 um 15:21 schrieb Thomas Heigl <th...@umschalt.com>:
> >
> > > Hi all,
> > >
> > > I was wondering if Wicket has a built-in mechanism for caching the
> > > generated byte[] of package resources. I use concatenated resource
> > bundles
> > > that are compressed using the YUI CSS/JS compressors.
> > >
> > > Using the default settings, compression is performed for every request
> > that
> > > does not have it in the client cache. Since this compression is a very
> > > complex operation I'd like to perform it only once.
> > >
> > > Cheers,
> > >
> > > Thomas
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Server side caching of generated resources
Posted by Thomas Heigl <th...@umschalt.com>.
Hi Michael,
This caches only the resource version, e.g. message digest, but not the
actual contents of the resouce.
Kind regards,
Thomas
On Mon, Jun 17, 2013 at 4:02 PM, Michael Haitz <mi...@1und1.de>wrote:
> Hi Thomas,
>
> it depends on your deployment mode:
>
> if (application.usesDevelopmentConfig())
> {
> // development mode:
> // use last-modified timestamp of packaged resource for resource
> caching
> // cache the version information for the lifetime of the current
> http request
> resourceVersion = new RequestCycleCachedResourceVersion(
> new LastModifiedResourceVersion());
> }
> else
> {
> // deployment mode:
> // use message digest over resource content for resource caching
> // cache the version information for the lifetime of the
> application
> resourceVersion = new CachingResourceVersion(new
> MessageDigestResourceVersion());
> }
>
> best,
> Michael
>
>
> Am 17.06.2013 um 15:21 schrieb Thomas Heigl <th...@umschalt.com>:
>
> > Hi all,
> >
> > I was wondering if Wicket has a built-in mechanism for caching the
> > generated byte[] of package resources. I use concatenated resource
> bundles
> > that are compressed using the YUI CSS/JS compressors.
> >
> > Using the default settings, compression is performed for every request
> that
> > does not have it in the client cache. Since this compression is a very
> > complex operation I'd like to perform it only once.
> >
> > Cheers,
> >
> > Thomas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Server side caching of generated resources
Posted by Thomas Heigl <th...@umschalt.com>.
Hey Michael,
Yeah respond.js is exactly what we are using. However, I overlooked that it
kind of supports CDN/X-Domain via a local proxy. The solution looks a bit
complicated but I'll give it a try now. If it works it would solve my
original issue.
Cheers,
Thomas
On Tue, Jun 18, 2013 at 10:11 AM, Michael Haitz <mi...@1und1.de>wrote:
> Hi,
>
> if you describe your process a bit more, i could help you out. In one of
> my projects we render additional/browser specific css files like all
> other css files (except the browser checks based on ClientProperties, no
> conditional comments and so on).
>
> Do you know https://github.com/scottjehl/Respond?
>
> best,
> Michael
>
> Am 17.06.2013 um 17:30 schrieb Thomas Heigl <th...@umschalt.com>:
>
> > Hey Michael,
> >
> > but isn't it enough to send the correct cache headers + a calculated
> >> filename that contains the hash of file?
> >
> >
> > I actually have aggressive caching and a CDN in front of my resources. So
> > in 90% of cases, a resource is only generated once per deployment. My
> > problem is that I need to fetch some resources directly from my origin to
> > support media queries for IE<=8 and avoid running into cross-domain
> issues.
> > So between 5 and 10% of users directly hit my origin for CSS resources
> and
> > the load generated by this is getting too high.
> >
> > Thanks a lot for your suggestions. I'll try to think of a solution that
> > does not involve Wicket.
> >
> > Cheers,
> >
> > Thomas
> >
> >
> >
> > On Mon, Jun 17, 2013 at 4:57 PM, Michael Haitz <michael.haitz@1und1.de
> >wrote:
> >
> >> Hi,
> >>
> >> but isn't it enough to send the correct cache headers + a calculated
> >> filename that contains the hash of file?
> >> I think caching on your container isn't the best option (using nginx or
> >> varnish or a CDN like Akamai or something similar is way better), else
> >> you've to compile each resource on all your containers and you need some
> >> heap space for the content.
> >>
> >> best,
> >> Michael
> >>
> >> Am 17.06.2013 um 16:02 schrieb Michael Haitz <mi...@1und1.de>
> >> :
> >>
> >>> Hi Thomas,
> >>>
> >>> it depends on your deployment mode:
> >>>
> >>> if (application.usesDevelopmentConfig())
> >>> {
> >>> // development mode:
> >>> // use last-modified timestamp of packaged resource for resource
> >> caching
> >>> // cache the version information for the lifetime of the current
> >> http request
> >>> resourceVersion = new RequestCycleCachedResourceVersion(
> >>> new LastModifiedResourceVersion());
> >>> }
> >>> else
> >>> {
> >>> // deployment mode:
> >>> // use message digest over resource content for resource caching
> >>> // cache the version information for the lifetime of the
> >> application
> >>> resourceVersion = new CachingResourceVersion(new
> >> MessageDigestResourceVersion());
> >>> }
> >>>
> >>> best,
> >>> Michael
> >>>
> >>>
> >>> Am 17.06.2013 um 15:21 schrieb Thomas Heigl <th...@umschalt.com>:
> >>>
> >>>> Hi all,
> >>>>
> >>>> I was wondering if Wicket has a built-in mechanism for caching the
> >>>> generated byte[] of package resources. I use concatenated resource
> >> bundles
> >>>> that are compressed using the YUI CSS/JS compressors.
> >>>>
> >>>> Using the default settings, compression is performed for every request
> >> that
> >>>> does not have it in the client cache. Since this compression is a very
> >>>> complex operation I'd like to perform it only once.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Thomas
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Server side caching of generated resources
Posted by Michael Haitz <mi...@1und1.de>.
Hi,
if you describe your process a bit more, i could help you out. In one of my projects we render additional/browser specific css files like all
other css files (except the browser checks based on ClientProperties, no conditional comments and so on).
Do you know https://github.com/scottjehl/Respond?
best,
Michael
Am 17.06.2013 um 17:30 schrieb Thomas Heigl <th...@umschalt.com>:
> Hey Michael,
>
> but isn't it enough to send the correct cache headers + a calculated
>> filename that contains the hash of file?
>
>
> I actually have aggressive caching and a CDN in front of my resources. So
> in 90% of cases, a resource is only generated once per deployment. My
> problem is that I need to fetch some resources directly from my origin to
> support media queries for IE<=8 and avoid running into cross-domain issues.
> So between 5 and 10% of users directly hit my origin for CSS resources and
> the load generated by this is getting too high.
>
> Thanks a lot for your suggestions. I'll try to think of a solution that
> does not involve Wicket.
>
> Cheers,
>
> Thomas
>
>
>
> On Mon, Jun 17, 2013 at 4:57 PM, Michael Haitz <mi...@1und1.de>wrote:
>
>> Hi,
>>
>> but isn't it enough to send the correct cache headers + a calculated
>> filename that contains the hash of file?
>> I think caching on your container isn't the best option (using nginx or
>> varnish or a CDN like Akamai or something similar is way better), else
>> you've to compile each resource on all your containers and you need some
>> heap space for the content.
>>
>> best,
>> Michael
>>
>> Am 17.06.2013 um 16:02 schrieb Michael Haitz <mi...@1und1.de>
>> :
>>
>>> Hi Thomas,
>>>
>>> it depends on your deployment mode:
>>>
>>> if (application.usesDevelopmentConfig())
>>> {
>>> // development mode:
>>> // use last-modified timestamp of packaged resource for resource
>> caching
>>> // cache the version information for the lifetime of the current
>> http request
>>> resourceVersion = new RequestCycleCachedResourceVersion(
>>> new LastModifiedResourceVersion());
>>> }
>>> else
>>> {
>>> // deployment mode:
>>> // use message digest over resource content for resource caching
>>> // cache the version information for the lifetime of the
>> application
>>> resourceVersion = new CachingResourceVersion(new
>> MessageDigestResourceVersion());
>>> }
>>>
>>> best,
>>> Michael
>>>
>>>
>>> Am 17.06.2013 um 15:21 schrieb Thomas Heigl <th...@umschalt.com>:
>>>
>>>> Hi all,
>>>>
>>>> I was wondering if Wicket has a built-in mechanism for caching the
>>>> generated byte[] of package resources. I use concatenated resource
>> bundles
>>>> that are compressed using the YUI CSS/JS compressors.
>>>>
>>>> Using the default settings, compression is performed for every request
>> that
>>>> does not have it in the client cache. Since this compression is a very
>>>> complex operation I'd like to perform it only once.
>>>>
>>>> Cheers,
>>>>
>>>> Thomas
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Server side caching of generated resources
Posted by Thomas Heigl <th...@umschalt.com>.
Hey Michael,
but isn't it enough to send the correct cache headers + a calculated
> filename that contains the hash of file?
I actually have aggressive caching and a CDN in front of my resources. So
in 90% of cases, a resource is only generated once per deployment. My
problem is that I need to fetch some resources directly from my origin to
support media queries for IE<=8 and avoid running into cross-domain issues.
So between 5 and 10% of users directly hit my origin for CSS resources and
the load generated by this is getting too high.
Thanks a lot for your suggestions. I'll try to think of a solution that
does not involve Wicket.
Cheers,
Thomas
On Mon, Jun 17, 2013 at 4:57 PM, Michael Haitz <mi...@1und1.de>wrote:
> Hi,
>
> but isn't it enough to send the correct cache headers + a calculated
> filename that contains the hash of file?
> I think caching on your container isn't the best option (using nginx or
> varnish or a CDN like Akamai or something similar is way better), else
> you've to compile each resource on all your containers and you need some
> heap space for the content.
>
> best,
> Michael
>
> Am 17.06.2013 um 16:02 schrieb Michael Haitz <mi...@1und1.de>
> :
>
> > Hi Thomas,
> >
> > it depends on your deployment mode:
> >
> > if (application.usesDevelopmentConfig())
> > {
> > // development mode:
> > // use last-modified timestamp of packaged resource for resource
> caching
> > // cache the version information for the lifetime of the current
> http request
> > resourceVersion = new RequestCycleCachedResourceVersion(
> > new LastModifiedResourceVersion());
> > }
> > else
> > {
> > // deployment mode:
> > // use message digest over resource content for resource caching
> > // cache the version information for the lifetime of the
> application
> > resourceVersion = new CachingResourceVersion(new
> MessageDigestResourceVersion());
> > }
> >
> > best,
> > Michael
> >
> >
> > Am 17.06.2013 um 15:21 schrieb Thomas Heigl <th...@umschalt.com>:
> >
> >> Hi all,
> >>
> >> I was wondering if Wicket has a built-in mechanism for caching the
> >> generated byte[] of package resources. I use concatenated resource
> bundles
> >> that are compressed using the YUI CSS/JS compressors.
> >>
> >> Using the default settings, compression is performed for every request
> that
> >> does not have it in the client cache. Since this compression is a very
> >> complex operation I'd like to perform it only once.
> >>
> >> Cheers,
> >>
> >> Thomas
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Server side caching of generated resources
Posted by Michael Haitz <mi...@1und1.de>.
Hi,
but isn't it enough to send the correct cache headers + a calculated filename that contains the hash of file?
I think caching on your container isn't the best option (using nginx or varnish or a CDN like Akamai or something similar is way better), else you've to compile each resource on all your containers and you need some heap space for the content.
best,
Michael
Am 17.06.2013 um 16:02 schrieb Michael Haitz <mi...@1und1.de>
:
> Hi Thomas,
>
> it depends on your deployment mode:
>
> if (application.usesDevelopmentConfig())
> {
> // development mode:
> // use last-modified timestamp of packaged resource for resource caching
> // cache the version information for the lifetime of the current http request
> resourceVersion = new RequestCycleCachedResourceVersion(
> new LastModifiedResourceVersion());
> }
> else
> {
> // deployment mode:
> // use message digest over resource content for resource caching
> // cache the version information for the lifetime of the application
> resourceVersion = new CachingResourceVersion(new MessageDigestResourceVersion());
> }
>
> best,
> Michael
>
>
> Am 17.06.2013 um 15:21 schrieb Thomas Heigl <th...@umschalt.com>:
>
>> Hi all,
>>
>> I was wondering if Wicket has a built-in mechanism for caching the
>> generated byte[] of package resources. I use concatenated resource bundles
>> that are compressed using the YUI CSS/JS compressors.
>>
>> Using the default settings, compression is performed for every request that
>> does not have it in the client cache. Since this compression is a very
>> complex operation I'd like to perform it only once.
>>
>> Cheers,
>>
>> Thomas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Server side caching of generated resources
Posted by Michael Haitz <mi...@1und1.de>.
Hi Thomas,
it depends on your deployment mode:
if (application.usesDevelopmentConfig())
{
// development mode:
// use last-modified timestamp of packaged resource for resource caching
// cache the version information for the lifetime of the current http request
resourceVersion = new RequestCycleCachedResourceVersion(
new LastModifiedResourceVersion());
}
else
{
// deployment mode:
// use message digest over resource content for resource caching
// cache the version information for the lifetime of the application
resourceVersion = new CachingResourceVersion(new MessageDigestResourceVersion());
}
best,
Michael
Am 17.06.2013 um 15:21 schrieb Thomas Heigl <th...@umschalt.com>:
> Hi all,
>
> I was wondering if Wicket has a built-in mechanism for caching the
> generated byte[] of package resources. I use concatenated resource bundles
> that are compressed using the YUI CSS/JS compressors.
>
> Using the default settings, compression is performed for every request that
> does not have it in the client cache. Since this compression is a very
> complex operation I'd like to perform it only once.
>
> Cheers,
>
> Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org