Maltfield Log/2020 Q1

My work log from the year 2020 Quarter 1. I intentionally made this verbose to make future admin's work easier when troubleshooting. The more keywords, error messages, etc that are listed in this log, the more helpful it will be for the future OSE Sysadmin.

See Also

1. Maltfield_Log
2. User:Maltfield
3. Special:Contributions/Maltfield

Sun Jan 12, 2019

1. Documentation of the Auroville Earth Institute office & their Auroville Earth Institute (exhibition room).

Sat Jan 11, 2019

1. Visited the Auroville Earth Institute office & their Auroville Earth Institute (exhibition room).

Thr Jan 02, 2019

1. Marcin asked why www.opensourceecology.org takes 5 seconds to load and what we can do to speed it up
2. I did some quick checking. There's a pretty absured number of assets requied to be downloaded to render our site. I did a quick search for "async" in the source code and couldn't find a single one. To fix this, here's my checklist TODO (but I doubt it's higher priority than Discourse; I asked for clairification from Marcin):
   1. Do a page load from a fresh session and watch the varnish logs for the client's IP. Verify that 100% of the assets requested on the front page are returned from the varnish cache. This essentially eliminates the fact that our server is running slow due to code, db calls, etc. This should be done first. We have tons of RAM, so if any assets are not there; we should modify the varnish config to make sure 100% of all front-page assets get cached by varnish.
   2. We should enumerate the assets from above and try disabling them in the browser one-by-one to see the effect. If any can be safely eliminated on all our sites, we should cut them out. This is not a trivial process, and it may be deferred until sufficient time to focus on this task is permitted.
   3. For remaining assets that are necessary, we'll want to minify and async them. We should research a very simple/fast/lightweight wordpress plugin that will do this for us in such a way that it itself creates a cache of the minified files so it's not wasting time doing the minification every time we have to make a call to the backend.
   4. We should research our CDN options. This should be taken seriously, as once we start using a CDN we could end-up injecting malicious content into our site that could be used to hack our users. Therefore, the CDN must be trustworthy so they won't be themselves malicious or neglegent enough to let themselves be unknowingly hacked by a malicous 3rd party.
   5. I sent an email to Fastly about their free CDN service for non-profits; more reasearch is needed though.
3. Here's my email response

Without any investigation at all, I would ignorantly assume that this
may be caused by loading some large static asset dependencies, such as
javascript, css, images, etc that are blocking the content from arriving
to the browser.

If I'm correct, the solution is usually to:

 1. cut out unnecessary dependencies,
 2. "minify" any required dependencies (removes comments & whitespace
	and compresses them to decrease their size),
 3. make those resources "asynchronous/non-blocking" if possible (so
	they load *after* the page loads),
 4. cache them on the server side (varnish; may already be done, but
	validation would be necessary),
 5. tell browsers to cache them on the client side, and
 6. put any static assets we can on a super-fast CDN.

To determine if I'm correct, we can run the site through some online
load speed tools. They will usually load the site in a virtual browser,
enumerate the assets that were required, and show you the time required
to download the assets and render the page. I just did this with Google
Page Insights. Here's the results:

 *
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.opensourceecology.org

The above page suggests some of the resources blocking our page load
include twitter, bootstrap (probably required by the wordpress theme
we're using), and jquery. Our non-CDN images look pretty small & sane
as-is. And we may be able to remove some CSS files. Maybe.

The lowest hanging fruit is probably:

 1. Test enabling gzip compression encoding in apache (and maybe needed
	in vanish/nginx too)

And the next-lowest fruit is:

 1. Research CDN options. We may be eligible for free service as a
	non-profit.

I just emailed fastly, which a quick google suggested they provide free
CDN for non-profits. There's probably other options. And we should do
our research on this. We don't want a "free" CDN service that (either
intentionally or because they were hacked) does some sketchy injection
of malicious content into our site's resources. That's essentially how
thousands of e-commerce sites were hacked and had hundreds of thousands
of credit cards stolen in the Magecart web skimming scandal in 2018..

 * https://en.wikipedia.org/wiki/Web_skimming

The more direct but more time consuming solution is sifting through all
the shit that our theme is using and cutting out the unnecessary fat and
minifying the rest.

Please let me know the priority of this task compared to the Discourse POC.


Cheers,

Michael Altfield
Senior System Administrator
PGP Fingerprint: 8A4B 0AF8 162F 3B6A 79B7  70D2 AA3E DF71 60E2 D97B

Open Source Ecology
www.opensourceecology.org