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


(Lee_Ars) #1

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?


(Lee_Ars) #2

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:


(Sam Saffron) #3

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.


(Jeff Atwood) #4

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


(Sam Saffron) #5

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.


(Lee_Ars) #6

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:


(Robin Ward) #7

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


(Kris) #8

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.


(Jeff Atwood) #9

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.


(Jeff Atwood) #10

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!


(Sam Saffron) #11

@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.

Homepage

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.


(Jeff Atwood) #12

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.


(Sam Saffron) #13

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


(Lee_Ars) #14

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:

Topic:


(Lee_Ars) #15

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!