front end performance consideration for production

[aarongundel]

describe the issue

We've been doing some testing on front end performance, and it appears that gzipping responses has an (relatively minor, but noteable) impact on response times. It is probably worth mentioning that in a production setting, performance may be improved by gzipping responses (cache policy will also factor, but I haven't tested that at this point). The method to do so varies by the server actually used. My own testing has involved nginx as a reverse proxy to arches.

please add links to existing docs or code (if relevant)

I am guessing this https://arches.readthedocs.io/en/stable/arches-in-production/ page would need to be modified and the page title changed to allow for other production considerations beside the debug variable. I am happy to make an effort here if desired.

which release does this issue concern?

all

[mradamcox]

Seems like a good idea. Something like this? https://ubiq.co/tech-blog/enable-gzip-compression-apache/

It would be nice to add nginx configuration instructions as well. Are you using uwsgi or gunicorn?

[aarongundel]

Hey Adam - yeah that's a great example for apache. For my own testing, I've just been fronting the dev server with nginx. I haven't attempted with wsgi or gunicorn, but that would be even better. The nginx docs have a section I used for configuration - https://docs.nginx.com/nginx/admin-guide/web-server/compression/ - it was pretty straightforward. I've been running the testing via two endpoints - one on the dev server side and the other on the nginx side which serve the same responses.

[mradamcox]

Ok nice, I think for this ticket we should specifically target apache, because for nginx to be involved in a production env we would first need to add documentation about uwsgi or gunicorn and that effort would be worth a separate ticket. @aarongundel if you want to tackle a some testing with gzipping on apache that would be great, but I'll try to do it too at some point too. Seems like it would be pretty straight forward to do.

[aarongundel]

Gotcha. That sounds good @mradamcox - I'm planning on doing some work with gunicorn/wsgi at some point anyway, so I will circle back on that later. As for apache, I'll try to find some time to test that out. I've been intending to set up a container to test Apache configuration out for a while so this is a good excuse. As part of this Apache testing it'll probably be worth it to test out cache-control policies as well, as those can also make a significant impact on load times.

[mradamcox]

Some testing on a staging server, but no luck. The map search page loads in ~16 seconds (dev tools reports 9.43mb / 4.87mb transferred), no matter what I tried. Just putting the following notes here for future reference:

[1] https://phoenixnap.com/kb/how-to-set-up-enable-htaccess-apache
[2] https://ubiq.co/tech-blog/enable-gzip-compression-apache/
[3] https://thegermancoder.com/2018/09/21/how-to-enable-compression-in-apache2/

In my site.conf I added

LoadModule deflate_module modules/mod_deflate.so (tried it both inside and outside of the VirtualHost)

As per [1], Added AllowOverride in the existing access directive for the static dir

    Alias /media/ /path/to/static/
    <Directory /path/to/static/>
       AllowOverride All
       Require all granted
    </Directory>

Created a .htaccess file inside of /path/to/static/.

For the content of this file, I tried the content in both [2] and [3], but no difference in the page load times/content.

[ekansa]

@aarongundel @mradamcox I added an example Nginx configuration that gzip compresses static assets for delivery to clients. It's now merged into the master branch. See it here: https://arches.readthedocs.io/en/latest/deployment/serving-arches-with-apache/#configure-nginx

Should we close out this ticket then?

[mradamcox]

I'm not sure the original idea in this ticket is completely covered yet, but will leave that up to Aaron. The nginx configs look good, though the intro section seems a little fractured. Also, the file name dictates the url so it's a little incongruous to have serving-arches-with-apache/#configure-nginx (even though the header has been updated in the menu), so it might be good to make a little more comprehensive overhaul to work in nginx. Just some thoughts.

[ekansa]

@mradamcox Those are some excellent suggestions. I'll make some refinements shortly!