Performance-Driven Development

BuckWoody — Tue, 11 May 2010 13:36:00 GMT

I was reading a blog yesterday about the evils of SELECT *. The author pointed out that it's almost always a bad idea to use SELECT * for a query, but in the case of SQL Azure (or any cloud database, for that matter) it's especially bad, since you're paying for each transmission that comes down the line. A very good point indeed.

This got me to thinking - shouldn't we treat ALL programming that way? In other words, wouldn't it make sense to pretend that we are paying for every chunk of data - a little less for a bit, a lot more for a BLOB or VARCHAR(MAX), that sort of thing? In effect, we really are paying for that. Which led me to the thought of Performance-Driven Development, or the act of programming with the goal of having the fastest code from the very outset. This isn't an original title, since a quick Bing-search shows me a couple of offerings from Forrester and a professional in Israel who already used that title, but the general idea I'm thinking of is assigning a "cost" to each code round-trip, be it network, storage, trip time and other variables, and then rewarding the developers that come up with the fastest code.

I wonder what kind of throughput and round-trip times you could get if your developers were paid on a scale of how fast the application performed...

Monitoring SQL Azure For Performance

BuckWoody — Tue, 22 Dec 2009 14:33:20 GMT

In SQL Server Azure, there are no Dynamic Management Views (DMVs) or Performance Monitor Objects and Counters that you can access, so you can’t run your standard performance monitoring that way. I suspect that as time goes on, SQL Azure will have some instrumentation, but for the time being, you’ll have to go with a different metric – round trip throughput.

What I mean by that is you’ll need to measure the start of a transaction and it’s completion. In the end, this is the only metric that matters anyway, but it is helpful to know what to fix – and this metric doesn’t help you with that.

What’s been working for me is to develop my queries locally using all my tricks and tools, and then post those up to SQL Azure. While it’s not a one-to-one map, it does seem to fit the bill for now. I’ll keep you posted.

Search results matching tags 'SQL Server', 'SQL Azure', and 'Performance Tuning'

Performance-Driven Development

Monitoring SQL Azure For Performance