Closed Bug 66176 Opened 24 years ago Closed 23 years ago

running with profile on remote drive significantly slows page load times

Categories

(Core :: Networking: Cache, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 74085
mozilla1.0

People

(Reporter: jrgmorrison, Assigned: gordon)

Details

(Keywords: perf)

So, I was doing some testing for bug 65315 (which was a nice win for the
loading of very large images no linux, courtesy of tor), and in the
process of doing the tests, I created a profile on a local disk
drive. Normally, I create my profiles in ~/.mozilla (the default), but
of course, /u/jrgm is an NFS mount point.

Anyhow, I got some times for linux that were substantially faster than
I normally get due to having my profile on a local drive. Overall, the
improvement was about 30%, with a range from 5% to 50% [all percentages
expressed as the difference between the times for local and remote
profiles, divided by time for the remote profile].

I did the equivalent test on macos9.0 and win2k (reversing the normal
situation and putting my profile on my WinNT Share on rocknrool). In
these tests, mac performance dropped by 65% (range 27% to 80%), and 
win32 performance dropped by 57% (7% to 88%).

Now, of course, performance has to be degraded if you run your profile
on a networked drive (cache, cookies, history, localstore, prefs being
resources that are actively accessed). But, the size of the
improvement was surprising (at least it was to me), and I didn't feel
that I should just drop this tidbit on the floor.

But, it may be that that is just the way things have to be (i.e.,
"Great John. Thanks for 'discovering' that networks are slower than
backplanes. Duh!" :-).
Keywords: perf
OS: Windows 2000 → All
Hardware: PC → All
Great John. Thanks for discovering that networks are slower than backplanes!

Seriously though, it would be interesting to see how much of the slowdown is each 
of the components.  I bet the fact that the cache folder is on the remote drive 
is most damaging.  We removed the UI to change the location of the cache folder 
from 6.0 due to lack of time.  If we can get that back in, that will make an 
improvement for those that go to the trouble of changing the default.  For the 
default case, the new cache design doesn't hit the disk for a cache miss, so I 
would expect to see some improvement there as well.

(And for my next trick, I will demonstrate that you can't push a rope ...)

So, if I set 'browser.cache.directory' to point back again to a local drive,  
is this all I need to do to get a "split" profile?

I wonder if a pair of quantify runs (either with or without that "split" 
profile) might be interesting.

I believe that's all it takes.  Splits runs would be great.
I did a "split" run on win2k (two brand new profiles, one on a remote NT share
with the cache pref pointing to a directory on a local hard drive, and the 
other profile with all contents on a local hard drive), and ran a page load 
timing test. There was no significant difference in the times recorded, so 
this slowdown is all cache related (and the slowdown has to happen, the only
question being how much, and whether there are opportunities to avoid I/O
as gordon notes above). 
Thanks John.  This is great info!

Now that you've eliminated the rest of the profile as the culprit, that leaves 
just two issues: the cache needs to minimize the frequency with which it hits the 
disk, and we need UI for setting the location of the disk cache folder.  I have 
some ideas how to address the first issue are incorporated in my proposed cache 
design changes, and we already have a bug on the second (bug 46490).
Cache bugs to Gordon
Assignee: neeti → gordon
Target Milestone: --- → mozilla1.0
I'm going to mark this as a duplicate of 74085, a request to store the default 
cache folder on a local volume.  This bug simply states the reason why we want 
bug 74085 fixed.


*** This bug has been marked as a duplicate of 74085 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
I can dig it, baby.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.