If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

getting to top crash reports is really slow

VERIFIED FIXED

Status

Socorro
General
P1
normal
VERIFIED FIXED
10 years ago
6 years ago

People

(Reporter: Samuel Sidler (old account; do not CC), Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Reported by chofmann, Today (4 hours ago)

What is the problem?
   go to http://crash-stats.mozilla.com/topcrasher

   click on something like the link to ->  Firefox 3.0b2  


What is the expected behavior? What happens instead?
   looks like the report might be generated on the fly and its really slow to show of list of the top crashers in the recent beta.

    we should run a nightly report and then cache it so we can quickly get
at a top 20 list for analysis.

--

Comment 1 by bsmedberg, Today (4 hours ago)

It is generated on the fly. Morgamic and aravind will be taking down the database for upgrades and tuning and partitioning sometime this week. I think that we should defer this for a very long time and allow the netscaler to cache this for a longer period of time if necessary.

--

Comment 2 by chofmann, Today (4 hours ago)

"very long time" as in 24 hours would be fine.  longer makes it possible that we
could miss critical issues that arise with changes in web content that might bring on a slew of incoming crash reports, and not see a stack signature make a big move up the charts.

it'd be nice to have a set of query reports that ran nightly, and another set that could be run on the fly. there will be lots of interesting ways we want to look at the data though a variety of reports, but each way should fall into wanting to view and analyze it base on a nightly snapshot, or have access to the latest incoming reports.

--

Comment 3 by bsmedberg, Today (4 hours ago)

I meant more like 60 minutes...

If we can keep the database happy, I'd prefer to avoid nightly snapshot queries, just to avoid complexity.

I think also, to avoid missing things moving up the charts, we should create a "new big crashers" report, which is filed here as in issue 75... that patch would need to be updated to trunk.

--

Comment 4 by morgamic, Today (2 hours ago)

There is a bug on this already, it's due to the size of the initial partition in the breakpad db, which will be attended to tonight during the maintenance window.  I mentioned this in the allhands yesterday morning.
(Reporter)

Comment 1

10 years ago
It seems kind of bad to cache this at the Netscaler level since, if I'm understanding correctly, one user will have to wait however long for the page to load every hour or so while everyone else will see the page practically immediately. Is there a reason we can't cache this at a code level or run this query on a cron?

(That might already be in intent, just going on what this bug says.)

I also don't see the aforementioned bug that was filed, unless it was resolved before I moved bugs over to Bugzilla.
Priority: -- → P1
Well, caching is fine, because if it's a new index it won't have a preexisting cache record so lookups by ID will work.

The window wasn't announced so this will wait until Thursday.  Working with IT to make sure it gets announced this time.

The other bug was bug 411181.  We can keep this one open, though.  The tracking bug for the actual partition creation is bug 411185.
(Reporter)

Comment 3

10 years ago
This is now fixed, as far as I can tell.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Updated

10 years ago
Status: RESOLVED → VERIFIED

Updated

10 years ago
Blocks: 411450
(Assignee)

Updated

6 years ago
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.