Open Bug 684646 Opened 13 years ago Updated 1 year ago

Detect Common performance problems and warn user

Categories

(Firefox :: General, defect)

x86
Windows 7
defect

Tracking

()

People

(Reporter: taras.mozilla, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [Snappy:p3])

Attachments

(1 file)

We need functionality into Firefox to conditionally kick in for people with >15second startups that would check for common causes of slow IO:
1) IO contention due to known windows services(windows media player and windows indexing service kickin on startup)
2) Antiviral software such as Norton or AVG

This should popup an info bar pointing to an article on the problem and how to fix it. 

The trick here would be to scan windows processes and see how much IO they do and then attribute that to the relevant highlevel notion of a windows service or another software product. Kevin, do you know how feasible this is for a non-privileged product?

I think as a prereq we should stick in some telemetry probes that would report this info back to us to see if we are even capable of detecting startup contention reliably.
Blocks: 572459
http://msdn.microsoft.com/en-us/library/ms684865%28v=vs.85%29.aspx
"All users have read access to the list of processes in the system"

If you can detect things just based on process name that would probably be easy to do regardless of whether you're running as guest. If you need access to the version information from the executable to get the name of the vendor (like Norton) you'll need read access to the folder where the executable lives - the bright side is that Program Files is always readable, so if they're sane and install it there, you should be able to open the executable and read the version info.
(In reply to Kevin Gadd (:kael) from comment #1)
> http://msdn.microsoft.com/en-us/library/ms684865%28v=vs.85%29.aspx
> "All users have read access to the list of processes in the system"
> 
> If you can detect things just based on process name that would probably be
> easy to do regardless of whether you're running as guest. If you need access
> to the version information from the executable to get the name of the vendor
> (like Norton) you'll need read access to the folder where the executable
> lives - the bright side is that Program Files is always readable, so if
> they're sane and install it there, you should be able to open the executable
> and read the version info.

Most of these IO suckers are due to svchost stuff, we need to be able to tell apart various kinds of svchost to detect the harmful ones.
One way is to create a mini file system filter driver to do this manually:
http://msdn.microsoft.com/en-us/windows/hardware/gg462968

...but could we just use a tool that already exists?

I mean something like perfmon?
You can access it programatically if needed or just use perfomon.exe.
You can see some nice overall stats like avg disk queue length per disk.

Another great tool is the sysinternals process monitor:
http://technet.microsoft.com/en-us/sysinternals/bb896645
It will show you every process in windows, you can filter on everything, and it shows all access times.
You can then save/export the data and parse it.  

You could also look into windows API hooking if process monitor doesn't meet your needs:
http://www.codeproject.com/KB/winsdk/MonitorWindowsFileSystem.aspx

There are also a number of commercial products that we can simply buy if it would dramatically help you for debugging.

I think using process monitor with some filters defined, and build a simple parser for the data would be best.
Let me know either way though as tools can be built, but I hope we don't need to spend our time building them.

Also I'm not sure if you use it, but for our process you could use the FILE_FLAG_NO_BUFFERING flag for open file operations (CreateFile) to get more consistent stats on windows.  
I think we can do a mini file system filter driver or API hooking for things that aren't our process which automatically sets this flag as well.
(In reply to Taras Glek (:taras) from comment #2)
> (In reply to Kevin Gadd (:kael) from comment #1)
> > http://msdn.microsoft.com/en-us/library/ms684865%28v=vs.85%29.aspx
> > "All users have read access to the list of processes in the system"
> > 
> > If you can detect things just based on process name that would probably be
> > easy to do regardless of whether you're running as guest. If you need access
> > to the version information from the executable to get the name of the vendor
> > (like Norton) you'll need read access to the folder where the executable
> > lives - the bright side is that Program Files is always readable, so if
> > they're sane and install it there, you should be able to open the executable
> > and read the version info.
> 
> Most of these IO suckers are due to svchost stuff, we need to be able to
> tell apart various kinds of svchost to detect the harmful ones.

If you know the filename for the IO sucker (x.dll, y.exe, etc) you can detect it inside a svchost instance using the debugging helper APIs. I think this might require administrator access, but it might be possible to enumerate as guest, especially if the services are running under the currently logged in user's account (instead of as Local System, etc).

If you highlight a svchost.exe process with the mouse in Process Explorer, the tooltip shows you which services are currently hosted within that process. I believe the way that works is roughly this:

1) Create a snapshot of the process in question using CreateToolhelp32Snapshot: http://msdn.microsoft.com/en-us/library/ms682489%28v=vs.85%29.aspx
2) Enumerate all the loaded modules in that process via Module32First and Module32Next: http://msdn.microsoft.com/en-us/library/ms684218%28v=VS.85%29.aspx
3) From the set of loaded modules, identify modules associated with a registered windows service. Services that run under svchost are configured that way in the registry, so you can just enumerate the registry entries for services to find ones that run under svchost (or outside it, for that matter).

There's also a simpler way on Windows XP and up, but I don't know if it works as non-administrator - the TASKLIST utility included with Windows can enumerate all running services:

C:\Users\Kevin>tasklist /svc /FI "imagename eq svchost.exe"
Image Name                     PID Services
========================= ======== ============================================
svchost.exe                    708 DcomLaunch, PlugPlay, Power
svchost.exe                    596 RpcEptMapper, RpcSs
svchost.exe                   1120 AudioSrv, Dhcp, eventlog,
                                   HomeGroupProvider, lmhosts, wscsvc

etc. You can leave off /FI to find *all* running services, regardless of the name of the process hosting them, as well. The service names are short-form, though, so to get a more detailed identifier of the service you'd want to look it up in the registry and then read the version info out of the executable(s) to get the company name, etc.
Whiteboard: [Snappy]
Whiteboard: [Snappy] → [Snappy:p3]
Cheng, what is the likelihood we could provide quality support articles to address these problems?
JP: I need context, sorry.  This makes no sense to me. If we're going to tell users generically: "Hey Firefox looks slow", I think the article isn't likely to get much traction with a lot of generic solutions... and if you're asking people to run a 3rd party tool and dig through registry entries, I'd say it's not worth the effort of writing it given how few people can figure it out.
Cheng, the idea is to have Firefox detect specific windows misconfiguration issues and present a support article on how to turn off windows file indexing, windows media player indexing, etc.
Ok, why don't we look at telemetry data and figure out what percentage of our slow responsiveness is covered by, say, the top 5-10 issues (that have usable solutions).

I think writing articles is fine and doable but we did try this with crash reports and found that even dozens of articles only covered a small percentage of crashes.
Making this bug more general. We have multiple sources of data that we should show to the user
a) We can detect common windows misconfiguration + AV issues
b) Report slow webpages
c) Use telemetry to inform the user of addons that are likely to be causing a problem

The main thing blocking progress at this point is that we need to design/implement a useful notification system.
Summary: Detect Common IO suckers on windows and warn user → Detect Common performance problems and warn user
Repeating from email:  Showing indicators of add-on performance can offer huge benefit to our users.  We know via Test Pilot that memory and startup-time intensive add-ons are one of the most consistent factors among poorly performing Firefox profiles.  So, giving users the ability to identify which add-ons they are "paying" performance for is very valuable.

This should be our goal: to identify to users the add-ons that are causing serious performance issues.  This gives users the ability to decide whether a particular add-on is "worth" a performance investment.  For instance, a web developer may see that a markup tool causes slower startup time, but keep it because it's valuable and possibly disable it when they are not developing.  For users who are not heavy add-on users, if they once installed an add-on that is memory intensive but not being used, they can disable or remove that add-on and enjoy an improved Firefox experience.

So, there's really no need to mark add-ons performing well.  What we implement should help users identify "heavy" add-ons.  This can finally improve our current situation, where performance problems are met with a blanket approach of "just disable all add-ons," as there's no way distinguish add-ons by performance.  The mockup attached how could do that by using our current icons and strings for notifications such as incompatibility.

As Blair pointed out on that thread, the text is just placeholder - we couldn't reliably know the specific amount of memory an add-on requires enough to say it here.

(In reply to Taras Glek (:taras) from comment #9)
> Making this bug more general.

We currently have a number of notification systems in place for problems we need to alert users of.  Surely there's a myriad of performance-related problems we *could* notify users of, but such a problem would need to meet an incredibly high bar.  If a user is frustrated with poor browser performance, merely giving them data about what's going wrong that they (in most cases) can't act on isn't necessarily going to serve their needs.  

One of the UX team's goals in designing Firefox is to keep interruption and notifications to an absolute minimum possible, only alerting users if something requires direct action (such as a request for permission) or places them in potential danger (such as a potential phishing site).  To alert users of problems like a slow page loading seems very redundant: the user would see the page loading slowly.  I think if we put an additional warning that an add-on causes a performance hit in the actual flow to install that add-on, this could be useful in the user's decision whether or not to install.  But, constantly alerting users to system problems probably isn't the goal here.
(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #10)
> (In reply to Taras Glek (:taras) from comment #9)
> > Making this bug more general.
> 
> We currently have a number of notification systems in place for problems we
> need to alert users of.  Surely there's a myriad of performance-related
> problems we *could* notify users of, but such a problem would need to meet
> an incredibly high bar.  If a user is frustrated with poor browser
> performance, merely giving them data about what's going wrong that they (in
> most cases) can't act on isn't necessarily going to serve their needs.  
> 

I agree about a high bar.
1) Some windows problems are really common and user can act on them by following a link to a sumo article on how to change stuff. Think of it as an oil change or low fuel indicator in the car.
2) Addons are a problem. No need to elaborate
3) Having a misbehaving tab open is a problem.
All 3 of the above are frequent, can be detected and the user would be better off by becoming more aware of them. IE does this well with offering to disable toolbars and other junk. 

As mentioned in the email, the problem with current proposal is that it lives in the addon manager. This needs to be more proactive. I think interrupting the user with a popup/dialog/(or custom tab?) is more ok when we detect firefox is misbehaving.
Assignee: nobody → necheverria
Assignee: necheverria → nobody
Depends on: 674779
Depends on: 778284
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 10 votes.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dtownsend)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dtownsend)
You need to log in before you can comment on or make changes to this bug.