Mercurial very slow over a VPN connection

Question

Our team has been using Mercurial for a while now and everything has been great. We all have a clone of the repositories and push/pull named branches to a centralized Windows server which is on our LAN accessed through a mapped drive.

The problem is that I've recently started working remotely and performance has degraded significantly. I connect to the office over VPN and access the shared drive just as I always have but what used to be 20-30 seconds pushes are now taking over 10 minutes!

I have a decent cable connection (30Mpbs/2Mbps) so I wouldn't expect small changes to take this long to push but it seems that no matter how small my change sets are many MBs are exchanged (from monitoring the network adapter during a push). This is the case even if I only modified one line in a source file. It also appears to be dependent on the repository size, the smaller the repository the better but it's never "fast".

I'm not familiar with what is involved in a Mercurial push but it seems like it needs to do a lot of back and forth between the main repository and mine to eventually decide on what to send.

I've just completed a push of 5 files where I added less than 5KB of code total and Here is the result of my hg push -b branch --debug --time over 13 minutes!

Is this "normal" over VPN or am I missing some critical configuration of some sort?

C:\inetpub\www\app1>hg push -b mynewbranch --new-branch --debug --time
pushing to X:\app1
query 1; heads
searching for changes
taking initial sample
searching: 2 queries
query 2; still undecided: 4, sample size is: 4
2 total queries
listing keys for "bookmarks"
5 changesets found
list of changesets:
7327fd8a913d019475783693fba7afc790bba11a
967e02cbdddb844b0cf1b67b452ff8e96614daa6
b5c9166ca22e98c499d71c9a0b7da2c36649f9f5
7e30ec219db545ba9309f7b8e8b015cf2a652383
79d028c22d2bc4554092ba5bad8249c7129d3caf
adding changesets
bundling: 1/5 changesets (20.00%)
bundling: 2/5 changesets (40.00%)
bundling: 3/5 changesets (60.00%)
bundling: 4/5 changesets (80.00%)
bundling: 5/5 changesets (100.00%)
bundling: 1/5 manifests (20.00%)
bundling: 2/5 manifests (40.00%)
bundling: 3/5 manifests (60.00%)
bundling: 4/5 manifests (80.00%)
bundling: Core/Module/Desktop/Display/file1.x 1/5 files (20.00%
)
bundling: Core/Module/Desktop/Display/file2.x 2/5 files (40.00%
)
bundling: Core/Module/Individual/Display/file3.x 3/5 files (60.00%
)
bundling: Core/Module/Individual/Forms/file4.x 4/5 files (80.
00%)
bundling: Public/Module/Desktop/file5.js 5/5 files (100.00%)
changesets: 1 chunks
add changeset 7327fd8a913d
changesets: 2 chunks
add changeset 967e02cbdddb
changesets: 3 chunks
add changeset b5c9166ca22e
changesets: 4 chunks
add changeset 7e30ec219db5
changesets: 5 chunks
add changeset 79d028c22d2b
adding manifests
manifests: 1/5 chunks (20.00%)
manifests: 2/5 chunks (40.00%)
manifests: 3/5 chunks (60.00%)
manifests: 4/5 chunks (80.00%)
adding file changes
adding Core/Module/Desktop/Display/file1.x revisions
files: 1/5 chunks (20.00%)
adding Core/Module/Desktop/Display/file2.x revisions
files: 2/5 chunks (40.00%)
adding Core/Module/Desktop/Display/file3.x revisions
files: 3/5 chunks (60.00%)
adding Core/Module/Desktop/Display/file4.x revisions
files: 4/5 chunks (80.00%)
adding Public/Module/Desktop/file5.js revisions
files: 5/5 chunks (100.00%)
added 5 changesets with 5 changes to 5 files (+1 heads)
listing keys for "phases"
try to push obsolete markers to remote
updating the branch cache
checking for updated bookmarks
listing keys for "bookmarks"
time: real 833.334 secs (user 0.577+0.000 sys 0.546+0.000)

C:\inetpub\www\app1>

Tracheitis

I often find that doing anything against a mapped network drive over a slow network takes forever. I would suggest serving the repository using 'hg serve' from a computer with fast access to the repository. – Lazaro

Answer 1

You're using Mercurial in a mode which assumes fast local access to the repository. Over a LAN that can be acceptable, but anything higher latency will produce the effect you're seeing. Latency isn't the only thing - using Mercurial in this mode will transfer files (or at least deltas) over your VPN uncompressed.

I would instead suggest that you get either hgweb.cgi or mercurial-server configured on your central server (that's currently publishing over a shared drive). I'd suggest this even when accessing over the LAN.

More information in general about publishing repositories.

Tallboy

Looks like this was the case, I've just tried using hg serve and wow! What a difference, instead of pushing MB over 10 minutes everything completed in less than 10 seconds flat. I'll look for a more permanent solution that doesn't use the mapping thanks for the link with resources on that. – Tracheitis

Quick update, I've set up hgweb with WSGI over Apache and pushes are faster than ever. Even faster than when I was at the office over the mapping :D Thanks again! – Tracheitis

Answer 2

I am inclined to suspect increased latency over the network when you communicate with the mapped network drive over VPN. Can you add --profile to your hg command and examine/post the output?

Mulligan

Thank you, I'll try that tomorrow and post back with the results. – Tracheitis

+1 this was the case. I've followed Tim's suggestion of using another protocol and it made a world of difference. – Tracheitis