Comments on: Response-time optimization in systems that are queued http://www.xaprb.com/blog/2009/12/09/response-time-optimization-in-systems-that-are-queued/ Stay curious! Mon, 06 Sep 2010 10:31:52 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Shlomi Noach http://www.xaprb.com/blog/2009/12/09/response-time-optimization-in-systems-that-are-queued/#comment-17546 Shlomi Noach Sun, 03 Jan 2010 19:44:08 +0000 http://www.xaprb.com/blog/?p=1456#comment-17546 Fernando, Yes, I think we agree here. Regards Fernando,

Yes, I think we agree here.

Regards

]]> By: Fernando Ipar http://www.xaprb.com/blog/2009/12/09/response-time-optimization-in-systems-that-are-queued/#comment-17545 Fernando Ipar Sun, 03 Jan 2010 19:29:17 +0000 http://www.xaprb.com/blog/?p=1456#comment-17545 Shlomi: I have a 3 year old and I'm still tired. I've been told it improves once they're married :) I understand your point, my point was more in line with what's on chapter 4 - 'Targeting the right improvement activity' So, back to my original message, 50% of SELECTS being full scans is something bad if you've identified this to be bad (now or in the future) for the business. If this particular server has a mostly write workload, and/or this 50% of identified selects are batches, or even better, if these 50% of selects are full scans over tables with very little data, which are cached for long periods of time after they're selected (imagine full table scans over things like SELECT country_id, country_name from countries to populate a country cache). So, back to your new example, I'm hired to audit a server with no current performance issues, and identify this full scan selects in 50% of the selects, first, I need to know what % of the total DB activity this represents. If the server has 90% read activity and >50%selects are full scans, I still need to check over what data the full scans are done. If it's like the countries example below, (i.e., not too often, little data, cached, and probably not going to grow too much with time) it's not that bad. Otherwise this would indeed be a good target for a performance improvement activity. I think the point is a metric alone, whatever it is, doesn't give you much info without context. I hope I'm making more sense now :) Regards Shlomi:

I have a 3 year old and I’m still tired. I’ve been told it improves once they’re married :)

I understand your point, my point was more in line with what’s on chapter 4 – ‘Targeting the right improvement activity’

So, back to my original message, 50% of SELECTS being full scans is something bad if you’ve identified this to be bad (now or in the future) for the business.

If this particular server has a mostly write workload, and/or this 50% of identified selects are batches, or even better, if these 50% of selects are full scans over tables with very little data, which are cached for long periods of time after they’re selected (imagine full table scans over things like SELECT country_id, country_name from countries to populate a country cache).

So, back to your new example, I’m hired to audit a server with no current performance issues, and identify this full scan selects in 50% of the selects, first, I need to know what % of the total DB activity this represents.

If the server has 90% read activity and >50%selects are full scans, I still need to check over what data the full scans are done. If it’s like the countries example below, (i.e., not too often, little data, cached, and probably not going to grow too much with time) it’s not that bad.
Otherwise this would indeed be a good target for a performance improvement activity.

I think the point is a metric alone, whatever it is, doesn’t give you much info without context.

I hope I’m making more sense now :)

Regards

]]> By: Shlomi Noach http://www.xaprb.com/blog/2009/12/09/response-time-optimization-in-systems-that-are-queued/#comment-17544 Shlomi Noach Sun, 03 Jan 2010 18:25:59 +0000 http://www.xaprb.com/blog/?p=1456#comment-17544 I'm very tired with a newborn; Fernando, the above is directed at you, of course. I’m very tired with a newborn; Fernando, the above is directed at you, of course.

]]> By: Shlomi Noach http://www.xaprb.com/blog/2009/12/09/response-time-optimization-in-systems-that-are-queued/#comment-17543 Shlomi Noach Sun, 03 Jan 2010 17:57:40 +0000 http://www.xaprb.com/blog/?p=1456#comment-17543 Hi Baron, I'm rather enjoying reading through the first few chapters of the book, though I suspect I won't be reading it all due to its Oracle nature, which I'm unfamiliar with. Yes, your point makes sense, and I agree that user response times are the most important factor, etc. But consider: you're auditing a MySQL server at the request of a customer. He isn't having trouble with the server, but he hired you to do a quick review. You recognize 50% of the queries are full scan. There are no performance problems! Wouldn't you take a look at the EXPLAIN plan to see *why* so many queries are slow? And assuming you did take a look, to find out some JOINs are incorrect (using join buffer, etc.); would you not recommend adding an index? Would it be wrong to *assume* that as workload grows, these queries will become a real issue? That was the thing I was trying to point out. I don't see the above as 'hunches'. I see them as proper programming methods. If queries are built correctly in the first place (again, just for the sake of the example), your app+db will scale better than they would if queries were badly planned. I think this is common sense. I'd like to hear your thoughts Regards Hi Baron,
I’m rather enjoying reading through the first few chapters of the book, though I suspect I won’t be reading it all due to its Oracle nature, which I’m unfamiliar with.
Yes, your point makes sense, and I agree that user response times are the most important factor, etc.
But consider: you’re auditing a MySQL server at the request of a customer. He isn’t having trouble with the server, but he hired you to do a quick review.
You recognize 50% of the queries are full scan. There are no performance problems! Wouldn’t you take a look at the EXPLAIN plan to see *why* so many queries are slow?
And assuming you did take a look, to find out some JOINs are incorrect (using join buffer, etc.); would you not recommend adding an index?
Would it be wrong to *assume* that as workload grows, these queries will become a real issue?
That was the thing I was trying to point out.

I don’t see the above as ‘hunches’. I see them as proper programming methods. If queries are built correctly in the first place (again, just for the sake of the example), your app+db will scale better than they would if queries were badly planned. I think this is common sense.

I’d like to hear your thoughts

Regards

]]> By: Fernando Ipar http://www.xaprb.com/blog/2009/12/09/response-time-optimization-in-systems-that-are-queued/#comment-17542 Fernando Ipar Sun, 03 Jan 2010 17:07:58 +0000 http://www.xaprb.com/blog/?p=1456#comment-17542 Shlomi: I think that, besides focusing on response time, another issue raised by Method R is that one has: - proper collected diagnostic info - scientific projections to support estimations So in your example, that would translate into questions like: - What projections made you arrive at the conclusion that full scans being present in about 50% of all SELECTS is a bad metric that will cause performance problems in the future? - How did you arrive at the number 'users double' or 'traffic increases 10 times more' If these are hunches, I think we should be growing beyond those by now. For instance, percentages can be deceiving. Perhaps even 80% of SELECTS in a server are full scans, but what if they only account for 10% of all active queries, and more, they are just batch jobs? In that case it may be fine that they aren't optimized in the traditional sense. Does that make more sense to you? Shlomi:

I think that, besides focusing on response time, another issue raised by Method R is that one has:

- proper collected diagnostic info
- scientific projections to support estimations

So in your example, that would translate into questions like:

- What projections made you arrive at the conclusion that full scans being present in about 50% of all SELECTS is a bad metric that will cause performance problems in the future?
- How did you arrive at the number ‘users double’ or ‘traffic increases 10 times more’

If these are hunches, I think we should be growing beyond those by now.

For instance, percentages can be deceiving. Perhaps even 80% of SELECTS in a server are full scans, but what if they only account for 10% of all active queries, and more, they are just batch jobs? In that case it may be fine that they aren’t optimized in the traditional sense.

Does that make more sense to you?

]]>