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