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

Answer 1

It depends on the type of application you are building, the complexity of the queries and the things your database engine and server lets you do.

If your database service only allows you to make simple SQL queries, less than 20 queries would be fine for a small, common webpage, but if it's the webpage for your university or a decision taking support application, 60 may not be enough.

If you have the privileges and your DBMS is capable (Oracle and such, compared to older versions of MySql for example), more than 20 queries asks that you start creating stored procedures, functions and triggers for the heavy tasks. In many cases you can't, so the number of queries naturally grows and you start using cache to ease the pressure on the server.

Some heavy tasks can be achieved in less queries using subqueries for example, but they are really heavy on the database engine. They aren't really recomended in some cases and should be used with care if they involve thousands of records.

The example up there from Vinko may be true for small, 1 week development "projects", but if you ask about Amazon, they don't use your common PHP / MySQL development package; behind the frontdoor lies a complex system of distributed computing and data-mining algorytms. If you're a newbie you shouldn't take big brothers like that for a reference...

Answer 2

Given that, short of using Ajax, each page is atomic, I haven't found it that difficult to generate quite complex pages in 3 or less queries. Conceptually, a typical page-set involves:

1. Context info (related to session and other global state);
2. Header (and related 1:0-1 joins);
3. Detail (1:M from 2).

It takes some planning ahead; but on the other hand it's an easy refactoring exercise in most cases.

Answer 3

The answer really depends on a few key things: - The amount of traffic of your site - The IT budget for your support - The complexity of the site and the resources required to optimize

If you have a website that gets a few hits a day, then who cares about 20 queries. On the flip side, if you are Amazon then you are going to offer the needed content at a large infrastructure cost.

Just about everyone else in the world is somewhere between those two extremes and has to balance based on their own resources.

The only other thing I'll say is caching is your friend.

Answer 4

You can usually bring all the data in two or three big queries instead of on twenty small ones. Minimizing the amount of queries is as important as, if not most important than, writing optimal queries to maximize performace.

Of course you should always analyze the query plans and aim towards optimal queries, be them small or big.

The thing is that badly designed webpages do many queries, one per each tiny little task, which could easily be grouped in a single query.

For example, a badly designed stackoverflow could do a query to get all the question ids it will show on the main page, then do one query per each question to get the summary and the votes. Then you have easily 20 useless queries. A well designed will do a single query getting all the information about all the questions it'll display.

Of course the impact of this all is reduced with good caching, which is what all big sites do, that way you actually can do a lot of queries and still get decent performance.

Answer 5

If you have to do 20 queries, then so be it, but it would make me a little nervous if it were a front page.

Combining queries where possible can help, but thinking about the caching is the most important part.

I am currently upgrading a site where data that changes 5 or 6 times a year is queried thousands of times a day, using some very nasty SQL to make it into a tree, but can be held as a tree structure in about 200k of RAM. (700k of viewstate on front page too, but that's another story...) These are the kind of things that cripple web sites for no good reason.

So, there is no magic number as to how many queries you should or should not do, but think about every one of them, even if you cache some of them for only 5 minutes, that will make a huge difference if ever you hit the front page of digg.

5 minutes of caching on just 1 query could remove thousands of DB hits when your site is under stress.

Answer 6

My rule of thumb is keep the front pages down to under 5-7 if possible, depending on the type of the site.

Interior pages, depending on what they need might have more, but I do what I can to keep it under 20.

However, at the same time, depending on what you are trying to do AND what types of caching you are doing with that information 20 may not be bad if 15 of them are heavily cached...