MLS Send/Receive Changes (Sync/Synchronize) very slow due to inefficient disk activity

[drepouille]

I do a Send/Receive early every Sunday morning, just so my finance clerk does not have to deal with all the "Do you want to print updated membership records?" prompts.
That is highly annoying.

[johnshaw]

With the advent of LCR it seems that the stake level clerks may be hurting themselves in the process... 5 years ago I'd never have imagined going months between MLS transmits, but the need to actually get into MLS is much smaller now.

Steve, it may be worth sending out a note to clerks, even at the ward level that syncing weekly is important to keeping MLS updated until it is retired. I can't imagine that there isn't someone at least weekly that could hit that button. To avoid every 2-3 months having to wait 30-45 minutes for a transmit to complete.

[davesudweeks]

I do a Send/Receive early every Sunday morning, just so my finance clerk does not have to deal with all the "Do you want to print updated membership records?" prompts.
That is highly annoying.

I don't consider it annoying, I consider it a hold-over from a bye-gone era when we had to maintain paper copies of everything. I do preview them each time just to make sure something isn't important (the annoying part is MLS doesn't tell you what the contents are it wants to print so you don't know unless you print or preview). There have been a few times I was glad I checked before skipping the print option.

This chapter will close forever when MLS goes away...

[Mikerowaved]

With the advent of LCR it seems that the stake level clerks may be hurting themselves in the process... 5 years ago I'd never have imagined going months between MLS transmits, but the need to actually get into MLS is much smaller now.

Good point. We still use MLS on the stake PC to scan and record temple recommends following an interview, so it's rare to go more than a couple of weeks without syncing.

[dajoker]

Everybody, thanks for responding. I haven't responded yet as I thought I would try some of the ideas first.

@dbapst - Thanks for chiming in. It's nice to hear it might not be all in my head. Perhaps, as scgallafent suggests, this has something to do with update frequency.

@johnshaw - Perhaps we are hurting ourselves, but a normal send/receive per week taking a minute, time four (4) weeks, does not add up to a half-hour every four (4) weeks. Perhaps the additional time comes from the big consolidated finance reports that come down, but most of the time watching MLS shows "Updating membership" and not "Updating finance", so I'm skeptical that is the issue, not to mention the big PDFs would be one transaction of one large object, not a ton of tiny transactions with new connections, so membership seems the most likely culprit. I think there's something else wrong here, and perhaps sending/receiving regularly masks it, and maybe that doesn't matter thanks to MLS's (hopefully) imminent demise.

@scgallafent - Two (2) great posts with lots of details; thanks for that. The bulk of my response is for you, as it sounds like you may have details that can help. This may all be moot, as MLS will hopefully be obsolete very soon, but I think there are still a few functions that need it.

I cannot see your second post from this page, but you mentioned setting up a new connection for each file transfer. Is there a reason a connection pool is not used for this? In my experience connection pools are pretty standard for this very reason; overhead isn't usually a big deal, especially where I usually work in corporate intranets with gigabit (or better) connections, but setting up TCP and TLS connections takes and wastes time, and it's a waste most software just avoids as a result. Perhaps it's not worth trying to fix this late in the game, and I would not have thought this is the whole of the problem (I haven't grabbed a LAN/wire trace recently to see how many connections are being setup), but if you're seeing a fairly consistent relationship between transactions (and thus files) and transfer times, perhaps it is the issue. Taking a second to transfer a few hundred bytes (or even a couple KiB) is really, really long, even on a dial-up connection (I remember being happy seeing 6 KiB/s on a dial-up connection a millennium ago), so maybe the connection setup (TLS included presumably for each one) is the cause, in which case a connection pool could help a lot.

Assuming it takes four (4) seconds per file (derived by taking a few of the times you cited, divided by the number of files involved, so significantly more than the single second per file) my latest transfer time of an hour and change, and the one before that of fifty-three (53) minutes or so, means many hundreds of changes. That sounds like a lot to people who aren't in IT, but it's a drop in the bucket for any computer, especially with the sizes you cited. Even replaying transactions in a database, and thus possibly working doing something unusual within the database that needs to move segments around among disk blocks, it doesn't add up well in my mind.

Perhaps more of that second (or four (4)) per file is taken on the server side, pulling out the individual transaction, in which case there is probably nothing MLS can do ot help directly, but if the transactions are built up as they happen that doesn't add up well either unless some kind of index allowing them to be found quickly is missing in the datastore.

Anyway, this is an interesting discussion, and I am interested to see if it can be resolved, but otherwise I guess we may just need to live with MLS as long as necessary, or just stop using it when possible. johnshaw mentioned perhaps we need to encourage clerks to send/receive more often, but that seems like a workaround to the bug at best. Sure, it may help spread out the time, but at what cost to our overall time? Taking an hour every month to send/receive is better than taking a couple hours every month if I go in weekly, since going weekly implies getting to the stake center, getting the computer started, and going home; even living close to the stake center (ten (10) minutes round trip if I drive, not bothering to get dressed up for the occasion) it's forty (40) minutes for no purpose since the bulk of what I do does not involve MLS anymore (thank-you!) and can be done from home (thank-you!!).

I'll see what I can find on the wire the next time I do a send/receive, maybe in a couple weeks once the monthly reports are ready.

Aaron Burgemeister
Stake Assistant Clerk - Finances