Drupal 10, the latest version of the open-source digital experience platform with even more features, is here.After completing an Aegir install on a VPS in the UK and successfully adding a remote server from within the same network I then wanted to add my other servers located in Australia and the US. Adding the server(s) worked perfectly, verifying a platform on the server also worked perfectly. It's only when you try and install a site on a platform on a geographically distant remote server do you come across problems.
After some discussions with skwashd he determined that it was due to the larger latency between the servers and MySQL's need for a positive response between each query. Hence the length of time for a site install was anywhere from 2 hours (for a very basic site) to 18 (for a more complex site) - the more complex site didn't actually finish in the end.
skwashd recommended installing the site on a platform on one of the closer remote servers (or even the aegir server itself) which worked perfectly (I do love Aegir!) and then migrating it to the remote server. This was an excellent workaround and allowed me to get the more complex site installs working.
However, the migrate process still took 2 hours and 10 minutes. Backups and restore can be up to an hour and this potentially means extended down time for a site when attempting to migrate.
Now, I realise the cause of this problem may be outside of the control of provision developers. I thought I would mention it as a feature request to see if there was a potential solution.
I love Aegir and everything it can do for me. But the geographically distant server issues are causing me a few hassles at the moment.










Comments
Comment #1
Steven Jones CreditAttribution: Steven Jones commentedJust to confirm a few things:
Your UK server has a web and DB server, and your US server also has a web and DB server?
You were trying to install the site on a platform registered with the US web server, and a the US DB server?
Or do you have a single DB server (in the UK) and all webs talk to that single DB server?
(DB server may reside on the same machine as the web server in any of the above)
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedThere is no doubt that there's lag with multiserver on such tasks such as migrate etc. I have seen this myself migrating sites between the US and France.
I *have* been able to identify where the bottlenecks are:
1) Dumping / transferring that dump of the database
2) Rebuilding permissions, (node access), clearing caches
Problem being I'm not convinced we're able to do much about it - or even if it's Aegir's problem to optimise or not the Drush calls that we rely on.
Comment #3
neurojavi CreditAttribution: neurojavi commentedHi:
I can confirm this issue.
- I have my hostmaster server in an UK VPS and a remote server in Spain (ping time=123 ms).
- Aegir version is 0.4 rc1
- This are some time messuraments for an empty site (fresh drupal install):
- Clone from HOSTMASTER to REMOTE -> 0:28:41 (+ import 0:09:01)
- Clone from REMOTE to HOSTMASTER -> 0:03:28 (+ import 0:00:04)
- Migrate from HOSTMASTER to REMOTE -> 0:33:37
- Migrate from REMOTE to HOSTMASTER -> 0:03:43
- Install on HOSTMASTER -> 0:00:10
- Install on REMOTE -> 0:14:44
- But the major problem is with an Open atrium install on a remote platform that is taking more than 4 hours and already is going on...
I don't know if this data is relevant...
Thanks.-
Comment #4
crea CreditAttribution: crea commentedSubs
Comment #5
Steven Jones CreditAttribution: Steven Jones commentedRight, we the issue here is that our drush command is running on the master server, talking to a DB server half-way around the world, which is super slow.
The solution for this one is going to be executing tasks on the same server as the site if possible, which is a 2.x issue.
Comment #6
ergonlogic