Hi Peter,
The simplest option is a create an empty page that just includes all
important CSS-es and JavaScripts and configure that page as a health check
URL in load balancer.
E.g.
Warmup.java:
@Import(stack = {"core"}, stylesheet = {"my.less"})
public class Warmup {
}
Warmup.tml
<html><head/><body/></html>
And /warmup defined in health-check. Because Amazon's load balancers first
need to hit health check URL at least a couple times before exposing an
instance, you can be sure that files are compiled/initialised before users
get access to your application. There are probably more clever ways to
solve your problem, but this one is quite easy.
Cezary
On Tue, Jul 5, 2016 at 3:07 PM, Peter Hvass <peter.hv...@jamesinnes.com>
wrote:
> Hello all,
>
> The solution is kind of obvious here though I just wanted to feel around
> for any alternatives.
>
> I'm deploying a small web application to a Tomcat 8 server handled by
> Amazon Web Service's Elastic Beanstalk service - load balancers etc. etc.
>
> This is quite a busy site - so we'll typically see around 100 concurrent
> users.
>
> When I deploy a new version of the web app, the 'first load' is very heavy
> - mostly due to LESS compilation (tapestry-webresources, wro4j). When 100
> concurrent users hit for that 'first load' the server immediately falls
> over in a 100% CPU death spiral.
>
> My workaround thus far has been to deploy the new version to a secondary
> server, access it for the first load myself and then throw it to the
> hordes. This is annoying and time-consuming.
>
> Ideally it would be great if LESS compilation could occur as part of
> building the WAR file rather than live on the server. We never make changes
> to files inside the WAR file directly. Has anyone been able to achieve
> this?
>
> Kind regards,
> Peter
>
