Open Stack

Martin,

django_compressor does handles creating aggregated and compressed files for
you. This isn't quite the same as C programs because it's not just due to
file size. For example, if you have 2 files many browsers will make two
separate connections to get each file. That mean negotiating a connection
(can include tls), and pulling down the file dealing with TCP slow-start.
This means one larger file is faster to download then multiple files that
are smaller in overall size.

To get a 304 Not Modified message you'll need to make sure your web server
is handling that. I've encountered horizon instances where 304 Not Modified
messages aren't happening.

Cheers,
Matt Farina


On Wed, Jan 21, 2015 at 5:40 AM, Martin Geisler <martin at geisler.net> wrote:

> Matthias Runge <mrunge at redhat.com> writes:
>
> > On 21/01/15 09:59, Martin Geisler wrote:
> >
> >>
> >> This seems to imply that users will download at least one .js file
> >> per dependency.
> >>
> >
> > Not necessarily. We still use django-compressor, which copies all
> > javascript into fewer files. E.g. here in my untweaked juno
> > environment, I just get 3 instead of 10-15 following your logic above.
> > (at least one js file per xstatic package).
>
> Cool, I did not know about this!
>
> Radomir said that this is run in a post-install hook for Horizon and
> that he's unsure how or if the distros re-run the scripts when the
> dependencies are installed. That is, if an updated version of the js-foo
> package is installed, all apps that depend on js-foo would need to have
> their JS bundles refreshed.
>
> Or maybe it's simply run every time Horizon is started?
>
> >> That's probably acceptable for an application like Horizon which
> >> users will be using again and again, but for most web applications,
> >> you don't want your users to download 10-20 small .js files, instead
> >> you want them to download one minified and compressed file with all
> >> the JavaScript code needed.
> >
> > see above :D
> >
> >>
> >> I'm just mentioning this since it's one way that web apps differ from
> >> how normal Linux apps are typically deployed. Basically, web apps
> >> prefer static compilation and discourages "dynamic linking".
> >
> > I'm not sure, I can really follow you here.
>
> I was trying to draw a parallel to how traditional (C) programs use
> dynamic when loading -- perfect for distributions since this allows them
> to patch a security problem just once and know that all programs that
> use the affected library will get the update since they dynamically load
> the library at runtime.
>
> Contrast this with static linking -- which is normally discouraged or
> forbidden by distributions since you'll have to recompile all dependant
> programs when you patch a library.
>
> I was thinking that web apps look like statically linked programs when
> they're deployed using compressed and minified sources for maximum
> performance.
>
> Let me add that this kind of optimization matters the most if your
> visitors who only visit the app once or rarely. With a file per
> dependency, they'll get poor performance since their browser won't have
> cached the files.
>
> For an app like Horizon it might not be as important: even if it loads a
> little slow on your first visit, you're likely to visit it many times as
> you admin your deployment and those subsequent visits will be faster.
> Still not as fast as they would be if the server could reply with a
> single "304 Not Modified", but probably fast enough.
>
> --
> Martin Geisler
>
> http://google.com/+MartinGeisler
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150121/142d54a2/attachment.html>