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.
More of My Free Training Videos
Brent Ozar
Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.
Follow Me:
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.
I love the conventional-wisdom-man voice you do.
By the way, who was that quote from “Do stuff by the book …”?
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.
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.
Absolutely the best presentation about scaling and not only SQL Server.
HA! Well, thanks, sir.
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.
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.
[...] Why Stack Exchange Isn’t in the Cloud. It’s about love, the love of computers, and what you love you don’t let other people own. Also How StackOverflow Scales with SQL Server [...]
[...] Why Stack Exchange Isn’t in the Cloud. It’s about love, the love of computers, and what you love you don’t let other people own. Also How StackOverflow Scales with SQL Server [...]
[...] How StackOverflow Scales with SQL Server (Video) with Brent Ozar – 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. [...]
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).
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.
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
That’s the correct link. You’ll need to read that page a little more closely.
[...] can find Brent at his website or on Twitter! (Here’s his video about how Stack Overflow scales with SQL Server.) posted November 23rd, 2011 under [...]
I thought the cost of SQL server was per socket not per core, or has this change in 2012?
Ian – yep, it’s changed in 2012, and it’s now by the core.
@Ian, just noticed that on their pricing page too… Interesting turn of events.
[...] THE LINK [...]
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.
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