Miniprofiler times - what's appropriate? What's fast? What's cause for concern?

I haven’t taken the time yet to disable the miniprofiler, and I occasionally glance up at it as I’m popping around adjusting things and posting test messages. I’d like to be able to make some intelligent judgements on performance by looking at it, but without knowing more about the expected ranges of timings I should be seeing, it’s not hugely more useful to me in judging site responsiveness than my eyes are.

I know I’m probably missing out on stuff and that there are lots of ways I could be taking advantage of the miniprofiler and its detail output if I were debugging, but I’m no good at that stuff (which is tending to be a recurring theme in my posts here! :blush:).

For example, I just did a shift-refresh on my forum’s front page, and I got a single line in the miniprofiler of 79.9ms:

Is that…is that good? I think what that’s telling me is that it takes longer to render and paint the page in my browser than it takes to generate it, so that’s good, assuming I’m reading that right.

Popping into /admin, I see two lines, one to get /admin/dashboard at 23.9ms and one to get /admin/dashboard/problems at 34.7ms. This seems quick—is it? Clicking around on messages, I get varying times; 300.9ms, 214.4ms, 156.9ms, 317.9ms, all executing action show.

Can one of you fine folks toss out some rough guidelines for what numbers we should be shooting at in the miniprofiler, and what would indicate a “fast” site versus one that’s struggling?


Wanted to give this a little bump and see if @sam or @supermathie had an opinion. I’ve fiddled around a bit with PostgreSQL cache settings (mainly modifying shared_buffers and work_mem) really more to see if it alters performance than with any specific tuning objectives in mind, but it’d still be nice if I knew some upper and lower bounds for what “good” means with the miniprofiler and Discourse.

The ultimate arbiter on whether or not a forum is “fast” is subjective, of course, and it looks pretty fast to me. But since we have the instrumentation already in place, it’d be nice if I knew how to read the numbers a little better :smile:

Your times look fine, here are some shots from this server:

Topic page:

Latest list:

Good is:

“latest” list reload (logged in) server time ~200ms
“typical post” reload (logged in server time ~300-400ms

It does highlight that we have plenty of room for improvement perf wise, both on the topic list and topic pages.


Looks quite a bit faster with all the performance work we did in the last few months:

Topic Page:

Latest list:

I am seeing:

“latest” list reload (logged in) server time ~ 110ms
“typical post” reload (logged in) server time ~ 250ms


Confirmed, also here:

Client side is faster than ever, I am getting first paint at 489ms, it used to be 1122ms … massive improvement, and I am noticing it.

I attribute this to work @eviltrout has done and latest ember upgrades.


Still seeing fine times on my end, too—a latest reload (with shift-refresh to override cache) of 102.6ms:

…and a typical post reload (also with shift-refresh) of about 200ms—here’s a representative example with 224.7ms:

@sam, here’s a shared miniprofiler output if you care—not sure how long they stay alive after clicking “share,” but there it is :smile:

The CSS changes that @awesomerobot did also made a big difference.

Guessing it’s largely because a lot of box-shadows were removed — rendering a dozen of those on a page can certainly hog some resources.

1 Like

I want to revisit this when @eviltrout gets us on Ember 1.10 either late next week or week after.

Based on benchmarks we expect 30% improvement client side.

1 Like

OK now that Ember 1.10 is in:

Topic page:

Latest list:

I don’t think meta was on HTTPS then, though, so that might explain some of it. Encryption ain’t free, yo!

Here is this topic page, May 2015 vs December 2013, side by side.

And the same for browser events

Certainly is a LOT more query time there @sam … but good news is even factoring in slower HTTPS (and more features, etc) we are doing as well as we were in December 2013 for perf!

@codinghorror we are actually doing better or same on both homepage and topic page despite the huge amounts of additional data in the DB and extra features.


Jul 12: 12 queries, 80ms SQL total 160ms
Today: 31 queries, 64ms SQL total 160ms

Topic page

Jul 12: 42 queries, 157ms SQL total 331ms
Today: 65 queries, 151ms SQL total 285ms

We are doing a lot more querying in the preload store, we should cut that down, but overall a lot less work in the DB on the home page.


Yeah I am kind of concerned by the fact that we run 1.5× more queries on the very same topic page today (43 sql in 2014, 64 sql in 2015) .

But overall we did not degrade, which factoring in code growth and https is not bad at all.


The big increase in queries is mostly around preload store, we got to fix that.


Performance here seems A-OK, too—this is also with mandatory SSL (though with SSL termination happening on a separate box with haproxy).

Front page:



Bumping this because it’s my thread and why not.

I’m super-pleased at the improvements in performance over the past year—you guys are doing excellent work.

Typical “latest” reload without local browser cache is down to <100ms:

And a typical topic reload is also super quick, at ~130ms:

Keep it up, @sam and team!


Topic page F5 reload

Latest page F5 reload


May 2015: 28 queries, 54ms SQL, total 140ms
Jan 2019: 39 queries, 219ms SQL, total 358ms

Topic page

May 2015: 64 queries, 189ms SQL, total 346ms
Jan 2019: 76 queries, 619ms SQL, total 812ms

Unless I am misreading this, it isn’t looking too good to me @sam, particularly for the topic page. I noticed it was a fair bit slower to reload topics on the new hardware when comparing with the 2017 Discourse numbers as well.

(Notice that forward and back button numbers are way better; the full F5 refresh is what we’re comparing here, again, if I am reading the topic correctly.)


Look through the SQL, is the read state query taking a large chunk of the time, you did accumulate a bunch over the years.

Agree we can improve stuff, for sure

1 Like

Looking at these numbers again… maybe the SQL has gotten a whooole lot slower with the AWS hosting meta is on? Breaking it down, looking only at SQL part of the results:


latest → 28 queries / 54ms = 2.0ms per query
topic → 64 queries / 189ms = 3.0ms per query


latest → 39 queries / 219ms = 5.6ms per query
topic → 76 queries / 619ms = 8.1ms per query

That’s so much worse … almost 3x longer per query across the board… :scream:

Depends, maybe one query is eating up 80% of the time, certainly happens for me on meta. Unread tracking and resolution is inherently expensive and fiendish to optimize.

Also, suggested topics is very very expensive

That does seem to be the case.

  • On latest page, I see one query taking 152ms, the next highest after that is 7ms, and most far lower.

  • On topic page, I see one query taking 173ms, the next highest after that is 3.7ms, and most far lower.

So basically, don’t be an admin, don’t carry a ton of read state and your results will be radically different. We should create a new admin account and re-run these tests. I tried that, but it didn’t work… we still need the new admin user to be in the “special” group to see miniprofiler… can you give that a test and compare the F5 times for topic list (homepage) and this topic?