[Systems] Wiki speed
bernie at codewiz.org
Wed Jun 24 12:29:54 EDT 2015
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 .
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
_ // Bernie Innocenti
More information about the Systems