Posted on 6 Comments

external tools by internal people, internal tools by external people?

I know the architect of the new Sun/MySQL query analyser, Mark Matthews, very well. Even though the tool is not OSS (and thus does not benefit from an OSS development model with early feedback in the design/development cycle, from many eyes) I know that Mark organises his designs and team in such a way that the resulting quality (barring interference) will always be very good. Anyone who uses Connector/J will surely attest to that. So I’d personally trust the result, based on my knowledge of the person who led the team. That’s still a form of semi-blind trust though, OSS development makes that unnecessary which is why I’d say an OSS dev model is preferred for most things. And the new tool is, of course, bundled with the MySQL Enterprise subscription model. You have to subscribe to that service to have access to the tool.

But back to the query analyser itself. I’m really fairly pleased with Sun/MySQL launching this, because it does appear to provide actual value for clients, without weird arrangements that make people cringe. Well done, Mark & MySQL!

Now we can make an interesting observation… as Baron already noted, there are some things that only the server knows. No proxy, packet sniffing, processlist or even show status can reveal all details in the required context. And running things like SHOW SESSION STATUS just adds extra overhead (an extra round trip to the server) after each query, so while that would provide many of the otherwise missing insights, it’s not really a desirable approach.
This is why I too regard extra instrumentation inside the server as vital. Yet:

– Sun/MySQL, owner of the MySQL codebase (which is GPL), makes tools that are independent from the server.
– Others (Percona, OurDelta) add extra instrumentation into the server, to enable better monitoring and tuning.

Most intriguing!

Posted on 6 Comments

6 thoughts on “external tools by internal people, internal tools by external people?

  1. Connector/J is great. It almost makes me willing to use Java. They have plans to do client-side monitoring with it and that can produce very interesting results especially if they add the ability to act on changes in performance.

  2. The overhead of the added I/O from slow-query logging, which is often held up as a reason to avoid it, pales in comparison to the overhead of running SHOW STATUS on a busy server with a big InnoDB buffer pool.

    But neither is good enough. Nor is a proxy-based solution.

    This is about to get interesting.

  3. Are the SHOW STATUS comments directed at the MySQL Query Analyzer?

    Because it doesn’t use SHOW STATUS at all… Not for Query Analysis anyway…

  4. Amendment to the above: “pales in comparison to the overhead of running SHOW STATUS on a busy server AFTER EACH QUERY.”

  5. And what software does that, precisely? MySQL Enterprise Query Analyzer sure doesn’t.

  6. Right, right — but that’s the only Proxy-based technique currently possible that WOULD get stats that you can only get internal to the server otherwise. And this is not a far fetched idea. Check articles that people have written about Proxy, and check MySQL Forge. People try to do this kind of thing, until they find out it kills the server.

Comments are closed.