806028 - Massive slowdown (about 5 minutes) in applying background updates on Windows

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Since the patch on bug 800532 has been landed on mozilla-central we notice with our Mozmill update tests a massive slowdown in the time when the downloaded update gets applied. It started with about 2 minutes on Oct 21st with an en-US build and ended up with about 6 minutes with a french build from yesterday. This is not acceptable, especially not when you opened the about window manually and are waiting for the update to being applied.

Steps:
1. Grab the french Nightly build from yesterday and install it: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/10/2012-10-25-03-06-20-mozilla-central-l10n/firefox-19.0a1.fr.win32.installer.exe

2. Open the about window and check for updates.

Now you will have to wait a couple of minutes before you can restart Firefox. The same is actually also happening for OS X, but it's not that long there ('only' about 1 minutes).

Please do not use a lower priority if the update is getting triggered by the user. In that case we should apply the update as fast as possible because that has been requested. But also updating in the background without any user interaction should not take more than 6 minutes to get the files updated.

Comment 1

[Brian R. Bondy [:bbondy]]

Are those machines very IO intensive other than the update itself?

I'm thinking we should probalby backout bug 800532 until we have time to investigate only doing the low priority when the update is not in the about box.

We could re-land bug 800532 after this bug is done and land them at the same time.

Any objections?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

No, Firefox is the only application which is running beside usual services on that machine.

Comment 3

[(no longer active)]

I think we should back out the Windows part.  This is precisely why I was arguing against rushing in the Windows fix in that bug...

Comment 4

[Jeff Muizelaar [:jrmuizel]]

(In reply to Ehsan Akhgari [:ehsan] from comment #3)
> I think we should back out the Windows part.  This is precisely why I was
> arguing against rushing in the Windows fix in that bug...

This sounds good to me.

Comment 5

[Brian R. Bondy [:bbondy]]

Actually, this is precisely why you were arguing against the Windows part:

> On OS X and Linux, we copy files to a userspace buffer and then write them 
> back to a kernel buffer.  On Windows, the data never hits the userpsace 
> buffers, so the copy will be faster.

Do you really think that takes 5 minutes more compared to OSX?

I still don't think that the difference in speed here is due to that, and I think it is either due to hardware differences, or MS' implementation of lower priority IO vs OSX's.  

I still think we should backout the whole patch since 1 minute may be too long on OSX.  Also we don't know if it's due to hardware or implementation differences between low priority support in the OS'.

Comment 6

[Brian R. Bondy [:bbondy]]

If anything, we probably wouldn't have noticed the OSX regression and so it's a good thing both things were landed at the same time.

Comment 7

[(no longer active)]

We were indeed aware of the fact that updates will be slower on OS X with this change.  The question of how much depends on how much IO is happening among other things.  I was saying that we don't have any evidence that this is a problem on Windows, so we don't need to fix it without knowing that.

But I think I've beat this argument to death and have nothing more to add.  Either a partial or complete backout is fine by me, as it seems like we can't reach consensus here.

Comment 8

[Brian R. Bondy [:bbondy]]

Let's do a full backout until we can provide evidence that OSX updates with low priority IO doesn't slow down updates that are done in the foreground.  It would be best to not do low priority at all in the case of visible updates.

Comment 9

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/22e4bae8fe65

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This hasn't been landed on mozilla-central yet, so reopening for final landing.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/22e4bae8fe65