Front page optimisation to relieve server load

[jrosindell]

Eric - "Each page load is currently 4MB of data and about 200 HTTP requests. That is a lot of traffic per visitor"

I wonder if we should rebuild the front page to load only an image at first for this animation, then the user has to press a button or be active on the page for 30s or more before it loads the full tree.

Another idea would be to load an image but have an embedded video that includes sound and speaking as well as the tree - a really professional job that we've been talking about anyway - might be a better intro and could be hosted externally as a source of yet more traffic? At least then people only get the expensive loads when they're in the tree view itself.

[jrosindell]

Eric suggests that the server could switch on a mode for when it's under heavy use that scales back the front page (and maybe other settings too)

[hyanwong]

Following up, this is previously what we decided:

We did discuss with James as to whether to make the “animation” on the front page a movie, but eventually he convinced us not. The main reason was that most people will go from the home page straight to the tree viewer somehow, and therefore will always end up loading the static tree files anyway, after one or two clicks. If they have already downloaded them from visiting the front page, then they will grab them from cache, and so the total amount of resource loading for a visitor (assuming they always go to a tree view too) will actually be less if we embed the tree on the front page than if they had to download a (potentially large) animated gif/pnb/mov as well as the tree files.

So I think that putting a movie on the front page might be a bit of a premature optimisation. But the ability to switch to a static image under heavy load would be really useful. Note that there are also other bits of the page that make DB queries (e.g. the news items) so we may still be stressing the DB on front page load. @lentinj may have useful idea here too.

[hyanwong]

... the ability to switch to a static image under heavy load would be really useful

I'm not sure how we actually do this, other than by hand if we notice problems. I guess it would be useful to have https://onezoom.org/index_static.html and https://onezoom.org/index_dynamic.html, and normally we point index.html to the dynamic one, but can run an "emergency script" to generate the static one and switch the main index page to point at this.

[lentinj]

I think @hyanwong is right; the whole point of onezoom is the treeviewer. If a significant proportion of visitors to the site visit the homepage and don't open on the tree viewer, then something has gone terribly wrong :) The tree viewer starts loading once the rest of the page has loaded pretty much, so on a slow network connection the end result is still pretty good.

I'd be tempted to stop the tour looping though, since if you just leave the homepage open then it's constantly rotating around, churning through CPU / network / server load as it goes. And if a user hasn't got the point after the first few rounds, they've probably wandered off and forgotten about it.

I'm reasonably sure I filed a ticket somewhere about setting cache headers on the homepage so a browser (and more importantly, Nginx or a CDN between you and the browser) will cache the generated output for the homepage for ~1min. There isn't anything on the home page that wouldn't mind being served to all users, and nobody would notice if there's a 1min lag on sponsorship updates (e.g.). This would be easier to retrofit into the infrastructure than a pre-generated copy, although would involve a little thought so we don't e.g. muddle up various language copies of the homepage. We could also apply the same to life.html whilst we're there.

Another thing which I think could significantly reduce server load, but has only floated around in my head thus far, is changing the node detail API so that instead of requesting exactly the nodes you want, you request a fixed range of OTTs. So instead of requesting 885651,885659,885661,... you request 885xxx and get the lot back. This is admittedly may be more stuff than immediately required, but it's one HTTP request, with one set of simpler DB queries to make, and more importantly these can also be cached by Nginx / a CDN like the above, so there's no extra DB load.