Is 20 SQL Queries per page load really considered a lot? [closed]

Answer 1

The number of queries isn't so important all the time. It's really how you handle connections. If you have connection pooling then it really doesn't matter and the physical location of the servers matters. If your servers are next to eachother in a data center setting up a connection is probably really fast. Most of the time your website spends loading if it's a database driven site is going to be spent waiting for connections to open and for the data to be fetched. Figure to open a connection it takes 100 - 300ms. So if you have to open 20 connections for each database access, that's 4 - 6 seconds just opening and closing connections.

Since Jeff Atwood is using LINQ, I'm assuming he's only opening a single connection, executing his 20 queries and then closing the connection. It all probably happens pretty quick.

Also, Jeff's database runs on the same physical machine and uses internal machine communication to communicate with the database and not a network so there really isn't any delay you'd associate with the TCP type connection opening. (He talked about this on the Hanselminutes podcast a few weeks ago.)

I have a similar configuration for one of my sites using LINQ and with the database on the same box. When I run the site on my local machine hitting the database on the server in another state, it takes up to 6 seconds to load a couple of the data heavy pages. When I run the site on the server, the page loads in less than a second because everything is local to the server.

Answer 2

I'm always late comer in a party, this is kind of 5 years late...

But to-the-point answer to this question would be that NUMBER OF QUERIES MATTERS LESS THAN TOTAL TIME TAKEN BY THE QUERIES.

If a large query with multiple joins and sub queries takes 20 secs to execute, then (I think) 20 small queries which take .20 secs in all are much better.

I find manage smaller queries much easier, well mainly because I cache every query, and I can reuse the data from that individual query again and again and again.....

Answer 3

It's more about caching.

If you're getting a high number of concurrent page views, and each page view does a lot of queries, it doesn't make a lot of sense to hit the database every. single. time. Especially when a lot of the data coming back will by semi-dynamic reference data that only changes every now and then (as opposed to session or real time data which is always changing).

You may as well cache those database results using memcached or something similar. You don't necessarily need to cache the whole page (although that is what most Wordpress caching plugins do), as this kills interactivity, but you can cache on a data-by-data basis.

There's also the issue of optimising the queries. Especially avoiding the dreaded N+1 situation where you do one query for a parent record, then an extra query for each of its children. The latency of the round trip back and forth to the database alone will kill your page rendering performance, not to mention cause grief on the DB itself.