700397 - Firefox 5-7 on Mac OS X network drives (AFP) is slow to the point of being unusable

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Rob Carlson]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

This is a mac shop.  All workstations  have network home drives (AFP).  Laptops have local home directories.

Upgraded all machines to Firefox 5, (then tried 6 and 7).    Loaded all new clean profiles on all network machines.  No extensions are loaded.  IPV6 disabled.  Prefetch disabled.  Machines are set to no proxy (there is no proxy server).  Layers acceleration disabled.  


Actual results:

Laptops with local home dirs were largely unaffected.  Network home workstations found Firefox slow to the point of unusability-- usually resulting in spinning wheel hangs. Sometimes Firefox can work well for a day, if one runs the command dscacheutil -flushcache as root, but then after a day or so Firefox becomes unusable again.  Safari and Google Chrome are unaffected and run with the same speed as they have always had. 

Users have been abandoning Firefox because they can't get any work done..


Expected results:

Firefox should work they way it did on version 3.x.

Comment 1

[Rob Carlson]

Behavior is the same on 8 as well...

Comment 3

[info]

I recommend regression testing this bug against Firefox 10.0, released today. Very preliminary testing on a *very* small sample of machines suggests that this bug may have been "fixed", along with https://bugzilla.mozilla.org/show_bug.cgi?id=701457.

Would love some corroboration on this.

Comment 4

[Wayne Mery (:wsmwk)]

Rob, do you still see the problem with version 10?

Comment 5

[info]

The Awesome bar is still unreliable to the point of making FF 10 undeployable. See https://bugzilla.mozilla.org/show_bug.cgi?id=717406

Comment 6

[Wayne Mery (:wsmwk)]

If Rob's issues are limited to awesome bar (he doesn't mention it) then this (or other bugs) is a duplicate

Comment 7

[info]

I can only speak to the *performance* issues listed here, which I saw, in spades, until 10.

The Awesome Bar issues are clearly a separate issue not a duplicate of this bug, since this bug appears to be fixed (still waiting on corroboration) but Awesome Bar issues persist in 10 as described in 717406.

Comment 8

[daitheflu]

The log on the server side shows entries like this :

IP 172.24.16.6 - - [12/Sep/2012:10:19:11 0100] "Delete places.sqlite-journal" 0 0 0

Which seems fine.

But here, the same entry repeats *20 or 30 times per second* ! And repeats every second. As a result, the CPU usage of the server itself increases a lot (from 5% to 15~20% here).

Also note that sometimes, we encounter the same with the cookies.sqlite-journal file.

The only solution I can think of by now is to uninstall Firefox from the clients :(

Comment 9

[Wayne Mery (:wsmwk)]

daitheflu, do you still see this issue?

Rob writes "we moved to all local home directories due to  caching issues— not just with FF."

Comment 10

[daitheflu]

(In reply to Wayne Mery (:wsmwk) from comment #9)
> daitheflu, do you still see this issue?
> 
> Rob writes "we moved to all local home directories due to  caching issues—
> not just with FF."

Yes, we do. We are still running OSX 10.6 (both server and clients) with FF profiles on AFP network share. We are now using Firefox 28.

Please tell me if you need more information :)

Comment 11

[Wayne Mery (:wsmwk)]

daitheflu, still see this in version 31?

(I'd test myself but I don't have Mac. A thunderbird 31 user reported success)

Comment 12

[daitheflu]

Hi Wayne,

We are still using Firefox 28. I didn't take the time to update.
Moreover, most of my users that were facing this issue are now using another webbrowser.

But I'll post an update as soon as I can confirm the issue (or not :) ).

Comment 13

[Wayne Mery (:wsmwk)]

please do

(In reply to daitheflu from comment #12)
> Hi Wayne,
> 
> We are still using Firefox 28. I didn't take the time to update.
> Moreover, most of my users that were facing this issue are now using another
> webbrowser.
> 
> But I'll post an update as soon as I can confirm the issue (or not :) ).

Comment 14

[daitheflu]

Hi Wayne,

Sorry for the lack of update.

The only complain I'm still getting is that Firefox takes a long time to quit. People have to to force-quit it to close their session :( But I don't think that's AFP related.

Apart from that, I have to admit that I haven't had any complain for monthes. BUT, please keep in mind that :
  - I have less users than before ;
  - I know that some of them have switched and are now using Safari.

I can still see that it causes a lot of I/O on the server (especially with the cookies.sqlite-journal file) but it's OK now (probably because I have less users).

So I don't really know if the issue still exists or if users are just dealing with it.
My guess is that the issue is fixed OR that it happens less often than before.

Comment 15

[Negritas Sergiu, Desktop QA]

Hello! I will close this issue with Resolved-WORKSFORME as per last comment and that this issue hasn't had any activity in the past 6 years. If the issue is still available in the latest fx versions please feel free to reopen it.

Thank you!