How many SQL queries per HTTP request is optimal?

Question

I know the answer to this question for the most part is "It Depends", however I wanted to see if anyone had some pointers.

We execute queries each request in ASP.NET MVC. Each request we need to get user rights information, and Various data for the Views that we are displaying. How many is too much, I know I should be conscious to the number of queries i am executing. I would assume if they are small queries and optimized out, half-a-dozen should be okay? Am I right?

What do you think?

Answer 1

Premature optimization is the root of all evil :)

First create your application, if it is sluggish you will have to determine the cause and optimize that part. Sure reducing the queries will save you time, but also optimizing those queries that you have to do.

You could spend a whole day shaving off 50% time spend off a query, that only took 2 milisecond to begin with, or spend 2 hours on removing some INNER JOINS that made another query took 10 seconds. Analyse whats wrong before you start optimising.

Answer 2

The optimal amount would be zero.

Given that this is most likely not achievable, the only reasonable thing to say about is: "As little as possible".

Answer 3

• Simplify your site design until it's as simple as possible, and still meeting your client's requirements.

• Cache information that can be cached.

• Pre-load information into the cache outside the request, where you can.

• Ask only for the information that you need in that request.

• If you need to make a lot of independant queries for a single request, parallelise the loading as much as possible.

What you're left with is the 'optimal' amount for that site. If that's too slow, you need to review the above again.

User rights information may be able to be cached, as may other common information you display everywhere.

You can probably get away with caching more than the requirements necessitate. For instance - you can probably cache 'live' information such as product stock levels, and the user's shopping cart. Use SQL Change Notifications to allow you to expire and repopulate the cache in the background.

Answer 4

As few as possible.

Use caching for lookups. Also store some light-weight data (such as permissions) in the session .

Answer 5

您可以根据需要制作任意数量的查询，直到您的网站速度过慢。

Answer 6

Q: Do you have a performance problem related to database queries?

Yes? A: Fewer than you have now.
No? A: The exact same number you have now.

If it ain't broke, don't fix it.

While refactoring and optimizing to save a few milliseconds is a fun and intellectually rewarding way for programmers to spend time, it is often a waste of time.

Also, changing your code to combine database requests could come at the cost of simplicity and maintainability in your code. That is, while it may be technically possible to combine several queries into one, that could require removing the conceptual isolation of business objects in your code, which is bad.

Answer 7

As many as necessary, but no more.

In other words, the performance bottlenecks will not come from the number of queries, but what you do in the queries and how you deal with the data (eg caching a huge yet static resultset might help).

Answer 8

Along with all the other recommendations of making fewer trips, it also depends on how much data is retrieved on each round trip. If it is just a few bytes, then it can probably be chatty and performance would not hurt. However, if each trip returns hundreds of kb, then your performance will hurt faster.

Answer 9

You have answered your own question " It depends ".

Although, trying to justify optimal number number of queries per HTTP request is not a legible scenario. If your SQL server has real good hardware support than you could run good number of queries in less time and have real low turn around time for the HTTP request. So basically, "it depends" as you rightly said.

Answer 10

As the comments above indicate, some caching is likely appropriate for your situation. And like your question suggests, the real answer is "it depends." Generally, the fewer the queries, the better since each query has a cost associated with it. You should examine your data model and your application's requirements to determine what is appropriate.

For example, if a user's rights are likely to be static during the user's session, it makes sense to cache the rights data so fewer queries are required. If aspects of the data displayed in your View are also static for a user's session, these could also be cached.