[Systems] Wiki speed

[Bernie Innocenti]

On 24/06/15 04:02, Sam P. wrote:
> Hi All,
>
> I just saw that the docker container on freedom that does the
> magical-wiki-visual-editor-node-js-service was not running, so that was
> why only the edit source thing was working :)
>
> IDK what happened there - did somebody restart docker on freedom?  or
> restart freedom?  all of the containers were down :(
>
> So about the visual editor, here were my tests on wiki-devel (running
> "time curl
> http://wiki-devel.sugarlabs.org/go/Welcome_to_the_Sugar_Labs_wiki >
> /dev/null" on sunjammer):
>
> * ~2sec average time with visual editor and all the others
> * ~1.5sec without visual editor => probs a bit of network cost, but not
> the whole thing
> * ~1.7sec without mobile front end (but with VE and all the others)
> * ~2sec without the media viewer lightbox (but with VE and all the others)
>
> Don't trust my test results, but  it would probably help a little to
> move VE together with the rest of the wiki.
>
> It would be pretty cool to containerize or chuck the wiki in a new VM.
> That would make it eaiser to move the VE thing onto the same machine.
> Moving it onto a newer OS could also let us play with HHVM, which seems
> to work nicely with media wiki [1][2].

LGTM. Can you and the other Sam (scg) work together on this?

I think the current docker setup is still too sketchy to run on justice 
alongside other production VMs. We need to ensure that each container 
has hard limits on all resources: cpu, memory, disk space and possibly 
even I/O bandwidth.

Without resource isolation, it's only a matter of time until a bug in 
one container takes down everything, including our primary nameserver on 
lightwave, the VMs for Paraguay and so on.

Secondarily, we need some sort of monitoring to see things like memory 
leaks and overloaded services. Without good graphs, setting resource 
limits becomes a game of guessing.

Can we solve both these problems before moving the wiki? I'm sure docker 
deployments around the world have similar requirements and developed 
similar solutions.

-- 
  _ // Bernie Innocenti
  \X/  http://codewiz.org