Baron Schwartz wrote:
My thoughts after skimming the blueprint online:
1 -- too much focus on counters. Counters are eye candy. So what if
you had 99 of these and 2 of those? When you're talking about
performance, you care about measuring two things: time and tasks.
Both are necessary. A counter isn't a task, to the user of a
database. A query is a task. If you're digging into the internals to
optimize individual queries, you might care about sub-tasks like sorts
and disk I/Os and such, but without knowing the time each execution of
the sub-task took, the knowledge of how many of them happened is
basically useless. It's a distraction.
Agreed.
2 -- following in MySQL's footsteps too much. One example: Slowlog
and global query log are redundant. There needs to be one log, and it
needs to be much richer.
One Log to rule them all, One Log to find them,
One Log to bring them all and in the darkness bind them.
> Look at the Percona patches to MySQL for
quick wins -- add things like thread/session ID, for example.
I can get this done today. It's an easy win.
> Add
timing information on tasks within the query. Add information on
whether the query did a sort, what its plan was, etc. The Percona
patches are actually not a great example here -- they are
directionally correct ("add more info") but you need to recognize that
they are an ugly compromise -- they add some can't-live-without
information without perturbing the server much. A greenfield design
should be much more ambitious; it should say not only "there was a
sort" (that's a counter, which I just finished mocking) but how big it
was, and how much time was spent in it. Postgres's log is another
example to look at.
Yes, this is an excellent idea. And, with protobuffer messages, its
also an easy task to store this data optionally when "turned on",
without affecting the performance of the logging mechanisms...
IMO everything should begin or end with queries, queries, queries.
That is the unit of work that a database server does. Everything else
-- I/O, sorts, blah blah -- should be a drill-down from (or drill-up
to) queries, queries, queries. Any of that stuff that isn't possible
to correlate to specific queries is just a curiosity. Again --
suppose I'm silly and I decide to figure out what I/O my server is
doing so much of -- so what? If I don't know how to blame the I/O
operations on queries, I can't reduce the I/O. (If I can start with
I/O operations and correlate them with queries, it is legitimate to
optimize bottom-up instead of top-down, so "drill-down" shouldn't be
the only approach.)
Understood, and excellent points.
I will now step aside and gesture towards Cary Millsap instead of
blathering on. Basically, Drizzle has the chance here to support
methodical investigation into performance -- realize that there is a
logical time+tasks approach to doing that, and build to support a
smart user, instead of throwing counters at the user and asking
him/her to try to second-guess what it really means :-)
Well put.
Cheers,
Jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
