The most popular tech Q&A site in the world serves 12-14 million web pages per day with Microsoft SQL Server 2008 R2. They’re passionate about performance, and they’ll share the scalability lessons they learned along the way. This session is aimed at production DBAs who manage SQL Servers that need to go faster and SQL programmers who don’t understand why their database won’t deliver queries quicker.
24 comments
Leave a comment
Kyle Brandt November 16, 2011 | 9:49 am
Another interesting trend I *think* I have noticed is a move from LINQ to more hand written queries (would need a dev to confirm for sure). Possibly because it is easier for `select *` statements (or just extraneous columns) to slip in. Also, since SQL is already a declarative language, tuning T-SQL with yet another abstraction layer I imagine is kind of a pain.
As I said though, you would need to check with the developers to make sure I am not making this up.
Michael J Swart November 16, 2011 | 11:45 am
I love the conventional-wisdom-man voice you do.
By the way, who was that quote from “Do stuff by the book …”?
Brent Ozar November 16, 2011 | 7:47 pm
HAHAHA, thanks. That voice just comes naturally.
I’m not sure if I’m allowed to say the client’s name, unfortunately, so I had to leave that out.
Kevin Montrose November 16, 2011 | 1:05 pm
Following up on Kyle’s comment.
While we’ve always had some plain SQL in our app, there has been a definitely trend away from LINQ in the last year or so. Places where we’ve always used SQL are generally those where we needed some construct you can’t (easily) express in LINQ, or where the “fetch and update” pattern of LINQ imposed too much overhead.
A tiny part of the migration was caused by the “SELECT *” problem, although that’s easy to solve with LINQ it’s also rather easy to forget to. The rest was actually the CPU cost of LINQ generating the query SQL and deserializing the resulting rows.
Fritz Schenk November 16, 2011 | 7:46 pm
Absolutely the best presentation about scaling and not only SQL Server.
Brent Ozar November 16, 2011 | 7:47 pm
HA! Well, thanks, sir.
Nin November 16, 2011 | 10:20 pm
Great webcast. I do not agree with Comparing and calculating != Querying completely, Sometime it is ok to do some calculation on SQL server, for example, If i have 1000 records and i just want to know the sum of amount column, I would prefer to use SUM function on SQL instead of bringing 1000 rows with amount to APP server and calculate the sum. In some cases we have to look at the amount of data we will be fetching from SQL.
Thanks for the webcast, I am going to share it with my DBA co-workers. We are in middle of rewriting an APP for a big bank and they are just not able to understand that why we are moving all business logic from SPs to Domain.
Marc Gravell November 18, 2011 | 1:53 am
Minor correction: actually, we *do* run mvc-mini-profiler 24×7 in production (for devs) – it is very very low impact, so spotting problems immediately is more important.
Pingback: Stuff The Internet Says On Scalability For November 18, 2011 | Krantenkoppen Tech
Pingback: | Blog | Stuff The Internet Says On Scalability For November 18, 2011
Pingback: Links for November 15th through November 18th — Vinny Carpenter's blog
piers7 November 21, 2011 | 6:55 am
Sorry to be a pedant, but the Chrome ad is not ‘live’ over the web, so doesn’t illustrate anything regarding the performance of the recipie site.
The ads use locally cached pages (and do say that in the ad), to illustrate how fast Chrome renders (and that alone).
Brent Ozar November 21, 2011 | 6:58 am
Piers – it’s not the Google ad that’s live, it’s the end user’s credentials. The customized end user portion of the page is what was live when it’s filmed.
Laurence November 22, 2011 | 5:09 am
Hi Brent,
Trying to find the “Glenn” script (www.brentozar.com/go/glenn) but link goes to a page of Glenn Berry’s blog posts.
Can you provide/correct the link?
Thanks
Brent Ozar November 22, 2011 | 5:11 am
That’s the correct link. You’ll need to read that page a little more closely.
Pingback: SE Podcast #28 – Brent Ozar - Blog – Stack Exchange
Ian November 24, 2011 | 7:09 am
I thought the cost of SQL server was per socket not per core, or has this change in 2012?
Brent Ozar November 24, 2011 | 7:37 am
Ian – yep, it’s changed in 2012, and it’s now by the core.
Stacey November 30, 2011 | 8:07 am
@Ian, just noticed that on their pricing page too… Interesting turn of events.
Pingback: Scaling SQL Server « Shawn P Hoffman
Mike April 29, 2012 | 10:21 am
Brent, Thank you for the excellent presentation. It’s very helpful.
One question: What is a two-socket server? Does that refer to CPU cores, CPUs, etc?
Thanks again.
Kendra Little April 29, 2012 | 11:22 am
Hey Mike,
“Socket” means physical processor socket. The main reason this term is used is just to distinguish the physical processor itself from the number of cores it has (with or without hyper threading).
Hope this helps!
Kendra
Pingback: Scaling SQL Server « Fast .NET
Pingback: Scalability: Links, News And Resources (2) | Angel "Java" Lopez on Blog