On Feb 22, 8:12 pm, Jeppe Nejsum Madsen <[email protected]> wrote: > On Sun, Feb 21, 2010 at 9:49 AM, Marius <[email protected]> wrote: > > Guys, > > > I'm starting to have second thoughts about having css or js combine > > (concatenation of multiple files into a single response) on lift side. > > I'm starting to question that real benefits as in production sites in > > many cases the lift app has a http reverse proxy front end that can > > serve static content js/css etc. Thus combining multiple js/css with > > simple tools seems more practical. > > > Thoughts? > > By simple tools I assume you mean at build time? How would this handle > classpath resources?
Yes on build time. /classpath/myresourcescombined.css will reside in the reverse proxy. This file will reside in the reverse proxy document root. > > I don't think that doing it on the lift side conflicts with the > reverse proxy. If everything is configured correctly, the proxy should > only fetch the resource from lift once, see that the resource expires > far in the future and cache it. > > There are a number of (I think) conflicting scenarios that Lift should > support: > > 1) Good defaults that deliver great performance out of the box without > too much hassle during development/build/deploy time. This is where I > think Lift combining resources would be used. I somehow disagree. IMO production tuning is necessary regardless of the web framework used. How do other frameworks behave in this are. I don't know of any that does the resources combining and claim that this is preferable then using the reverse proxy. > 2) The absolute best performance no matter what. I think this is a utopia.In my experience having reverse proxies serving static content (combined wherever possible) will give you "best" performance. The application server should not be burden with serving static content as long as there are cheap reverse proxies out there. > This probably > includes multiple hosts for static resources, CDNs etc. If you're > going this route you're willing to sacrifice ease of use for that last > ounce of speed. Application performance should be tuned in production environments. I don't see where the "ease of use" sacrifice is. Lift apps will function properly without a reverse proxy but the reverse proxy is much more suitable for serving static content than the application server which will be burden with other requests. > > If/when load time becomes an issue for us this will be one of the > first things I'll try to investigate :-) > > /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
