Increase migration speed
The current Migration Manager (Linux) is painfully slow. A full server migration (+/- 300GB of data) over Gigabit takes more then 12 hours. During this time lots of website will have changed MySQL data getting lost after the migration.
The issue with the migration system in its current state is that if does site-by-site migration. If migrates site A, then goes to site B, then C, etc, etc. Because each site migration consists of a alot of different steps the servers are mostly waiting for each other to finish some process like creating mailboxes.
The load on both the source and destination server remains almost zero, which is another indication the servers are mostly waiting for each other.
The speed could increase considerably if Plesk would migrate more sites at the same time. Basically splitting the migration up into eg. 10 seperate migration processes would probably increasse the migration speed tenfold.
Ofcourse a better way would be to make the system a bit smarter. The source server doesn't have to wait for site B's MySQL databases to get dumped when the destination server is still importing the migration for site A.
Whatever the solution, the current migration system is way too slow.
Tozz
shared this idea
In 12.5 we changed from PMM that performed operations step by step to Migrator extension, which performs data transfer in multiple data streams. The feature to make it fully asynchronous operations not only for transfer stage as well as other performance improvements (specifically for Windows migrations) is in the cards.
Please let us know on https://talk.plesk.com if still have problems with migration speed.
—AK
-
Mik
commented
Still slow.
-
Andrej Walilko
commented
some of the issue is that data is packaged up first and the copied and unpackaged. this can be skipped to save a lot of time, and run data syncs in the background. for instance, package only the configuration for domain A, then copy and restore that small xml file. a data sync of email, databases, and web data can then be queued to the background while domain B's configuration is packaged.