Comments on: Top Crashers By Url and MTBF http://blog.mozilla.com/webdev/2008/12/30/top-crashers-by-url-and-mtbf/ Everybody Likes Ninjas Wed, 01 Feb 2012 08:03:02 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Ian M http://blog.mozilla.com/webdev/2008/12/30/top-crashers-by-url-and-mtbf/comment-page-1/#comment-179588 Ian M Mon, 05 Jan 2009 17:15:09 +0000 http://blog.mozilla.com/webdev/?p=133#comment-179588 +1 to Justin Dolske's suggestion. You could use stats like Alexa Rank, Google PageRank (page-based not site-based) or (US-only) Compete.com as well. Compete.com data you can download a dump file (with license restrictions but I imagine they'd give it free for the free publicity they'd get). There are backdoor ways of getting the other two stats, and probably other useful stats out there too. +1 to Justin Dolske’s suggestion.

You could use stats like Alexa Rank, Google PageRank (page-based not site-based) or (US-only) Compete.com as well.

Compete.com data you can download a dump file (with license restrictions but I imagine they’d give it free for the free publicity they’d get). There are backdoor ways of getting the other two stats, and probably other useful stats out there too.

]]> By: aking http://blog.mozilla.com/webdev/2008/12/30/top-crashers-by-url-and-mtbf/comment-page-1/#comment-178814 aking Wed, 31 Dec 2008 20:07:51 +0000 http://blog.mozilla.com/webdev/?p=133#comment-178814 The frontend of MTBF got the least love in this release as most of the time was on the backend. Justin, we will be smoothing values over 10 day average, as well as refining start and stop dates for the window. The frontend of MTBF got the least love in this release as most of the time was on the backend. Justin, we will be smoothing values over 10 day average, as well as refining start and stop dates for the window.

]]> By: bernd http://blog.mozilla.com/webdev/2008/12/30/top-crashers-by-url-and-mtbf/comment-page-1/#comment-178750 bernd Wed, 31 Dec 2008 09:07:42 +0000 http://blog.mozilla.com/webdev/?p=133#comment-178750 http://crash-stats.mozilla.com/mtbf/of/Firefox/major when drilling down on OS Firefox 3.0.5 Mac shows 15E6 seconds of MTBF on the third day, however there are only 259 200 seconds elapsed in this time. This is probably just a script error like dividing by 0. http://crash-stats.mozilla.com/mtbf/of/Firefox/major

when drilling down on OS Firefox 3.0.5 Mac shows 15E6 seconds of MTBF on the third day, however there are only 259 200 seconds elapsed in this time. This is probably just a script error like dividing by 0.

]]> By: DigDug http://blog.mozilla.com/webdev/2008/12/30/top-crashers-by-url-and-mtbf/comment-page-1/#comment-178706 DigDug Wed, 31 Dec 2008 03:53:10 +0000 http://blog.mozilla.com/webdev/?p=133#comment-178706 Forgive the rant, but someone at Mozilla needs to start putting real labels on their graph axises. Log or semi log plots are nice too. Either that, or scale the axis to get rid of the noise points which mean... well... nothing. Forgive the rant, but someone at Mozilla needs to start putting real labels on their graph axises. Log or semi log plots are nice too. Either that, or scale the axis to get rid of the noise points which mean… well… nothing.

]]> By: Justin Dolske http://blog.mozilla.com/webdev/2008/12/30/top-crashers-by-url-and-mtbf/comment-page-1/#comment-178693 Justin Dolske Wed, 31 Dec 2008 02:36:08 +0000 http://blog.mozilla.com/webdev/?p=133#comment-178693 It would also be interesting to have a "top crashers by domain/url" that's weighted by the site's popularity. In a perfect (Big Brother) world this would be "crashes per visit", but using something like comScore rankings might be a good proxy. This would allow looking for sites that are inherently crashy for us. In other words, the top 3 domains on the list (facebook, google, youtube) are there in large part just because they have so much traffic, not because Firefox is terribly crashy there. Well, probably. There's a lot of JS on Gmail, so who knows? Maybe we are abnormally crashy, it's hard to say either way with the current data. What's with the spikes on some of the MTBF graphs? Surely we're not putting out random builds that are amazingly stable? :-) Are these data glitches that can be filtered out, so the graphs don't look like flat lines with a few spikes? A MTBF list that's binned MTBF counts (10 users crashed after 30 minutes, 20 users after 60 minutes, etc) would also be interesting to see. I wouldn't expect crashes to vary that much by day-of-release -- it's the same code. It would also be interesting to see if the crash reporter could include the number of page loads for the session (or something similar), to look at stable-but-idle vs stable-and-busy. Anyway, overall great stuff! It would also be interesting to have a “top crashers by domain/url” that’s weighted by the site’s popularity. In a perfect (Big Brother) world this would be “crashes per visit”, but using something like comScore rankings might be a good proxy.

This would allow looking for sites that are inherently crashy for us. In other words, the top 3 domains on the list (facebook, google, youtube) are there in large part just because they have so much traffic, not because Firefox is terribly crashy there. Well, probably. There’s a lot of JS on Gmail, so who knows? Maybe we are abnormally crashy, it’s hard to say either way with the current data.

What’s with the spikes on some of the MTBF graphs? Surely we’re not putting out random builds that are amazingly stable? :-) Are these data glitches that can be filtered out, so the graphs don’t look like flat lines with a few spikes?

A MTBF list that’s binned MTBF counts (10 users crashed after 30 minutes, 20 users after 60 minutes, etc) would also be interesting to see. I wouldn’t expect crashes to vary that much by day-of-release — it’s the same code.

It would also be interesting to see if the crash reporter could include the number of page loads for the session (or something similar), to look at stable-but-idle vs stable-and-busy.

Anyway, overall great stuff!

]]>