[Moin-user] Multi-location moinmoin implementation?

[coolnodje]

I got a moinmoin instance setup at DigitalOcean Singapore, it's super
fast from a good connection in Beijing (ping ~80ms).
Highly recommend it, and it's pretty cheap.

Here's my referral code if you want to be nice
(https://www.digitalocean.com/?refcode=45ba3d2ace05 )

cheers
> Thomas Waldmann <mailto:tw at waldmann-edv.de>
> 30 June 2014 12:19
> Moin Philip,
>
> I don't run such setups, but I hope this might be helpful nevertheless:
>
>> We currently running our moinmoin wiki on an Amazon instance in North
>> Virginia. We have people in China who are trying to access it and are
>> reporting very poor access performance.
>
> Can have many reasons.
> Slow local internet connection at the user's site.
> Slow regional network there.
> High latency / slow international connection.
> Even different system loads due to different typical usage hours.
>
>> I'm thinking that one way of
>> solving the problem would be to set up a second server in a location
>> nearer to China, e.g. Tokyo or Singapore.
>
> Sounds reasonable. But maybe ask some people in china if that really
> helps / do comparative speed/latency tests.
>
>> Off the top of my head, it would seem to be relatively straightforward
>> to set up the Asia instance as read-only and then use rsync to
>> replicate changes from the US instance to Asia.
>
> Yes, that would work.
>
> Do a maint cleancache and a moin process restart after rsyncing.
>
> If you run exactly same python version, cpu architecture and maybe also
> otherwise same-setup, you can maybe get away without cleancache.
>
>> I could then use
>> Amazon's geo technology to redirect users to the "nearest" server.
>
> Maybe don't. Just have the servers at different URLs, so that people can
> decide which one to use (read-only one for fast reading / searching, the
> master for editing).
>
>> 2. Ideally, both servers would be writeable and I'd be syncing in both
>> directions but there is the risk of a collision then with two
>> different people editing the same page at the same time. It would be a
>> small risk, but the risk is there.
>
> Right. Maybe the r/w master and r/o replica is simpler.
>
> A third theoretical option is to set up a web proxy (squid, varnish,
> ...) near/inside china. But as wiki contents can change any time,
> effectively caching them is non-trivial / not possible without risking
> strange effects.
>
> Cheers,
>
> Thomas
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Moin-user mailing list
> Moin-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/moin-user
> Philip Colmer <mailto:philip.colmer at linaro.org>
> 24 June 2014 11:42
> Hi
>
> We currently running our moinmoin wiki on an Amazon instance in North
> Virginia. We have people in China who are trying to access it and are
> reporting very poor access performance. I'm thinking that one way of
> solving the problem would be to set up a second server in a location
> nearer to China, e.g. Tokyo or Singapore.
>
> Off the top of my head, it would seem to be relatively straightforward
> to set up the Asia instance as read-only and then use rsync to
> replicate changes from the US instance to Asia. I could then use
> Amazon's geo technology to redirect users to the "nearest" server.
> However, there are some problems/challenges with this approach.
>
> 1. If a user gets directed to the Asia server, what happens if they
> want to edit? I could potentially redirect the Edit links to the US
> server by using an explicit URL that bypasses the Amazon cleverness,
> but then the user could end up permanently on that server.
>
> 2. Ideally, both servers would be writeable and I'd be syncing in both
> directions but there is the risk of a collision then with two
> different people editing the same page at the same time. It would be a
> small risk, but the risk is there.
>
> Has anyone tried to tackle this sort of requirement before? Or anyone
> got any suggestions or recommendations on how to tackle it?
>
> Thanks.
>
> Philip
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community
> Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Moin-user mailing list
> Moin-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/moin-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140630/c8522df5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140630/c8522df5/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140630/c8522df5/attachment-0001.jpg>