What's faster?

mySQL query or include()?

[4string]

If I have some html content (a whole page) and I want to load it dynamically, is it faster to load an html file as an include or load it from a longtext field in my db?

Any insights would be helpful.

Thanks,
4

[DanA]

includes are usually much faster.

[ergophobe]

As a general rule: If you know where the data is stored, it's always faster to use the filesystem. If you will have to search through data, a database will be faster.

So when accessing a thread, WebmasterWorld just goes straight to the file system. Each thread is a file. This works great for serving up pages with the lowest overhead, but it is a major stumbling block to getting good site search going.

[4string]

Thanks to you both.

I didn't realize that's how WW works.

Now what if I have to check the db for, say, a file id number and then load an html file as an include? Would that still be faster? Or, since I'm already doing a query, is it an added step?

[ergophobe]

You would probably need to benchmark that. As the file read will be very fast, there's probably not much difference, but it might depend on how busy the DB server is, how much memory is available.

The thing is, if you are not serving up tons of pages concurrent, you will not see a difference with the this. Opening the connection to the DB and sending the query is costly, getting an extra couple of columns should not be that costly.

Realistically, any page that renders with just a couple DB calls is still going to be really fast. Some CMS systems can send over 100 DB requests for "static" pages and when you get into something that's gathering price lists, navigation structure etc etc etc from the DB, large numbers of calls is quite common.

[4string]

I guess I underestimate just how many DB calls I can make. I try to keep it down to 1 or 2 on a page. Maybe I shouldn't give it so much thought. I haven't yet built a site like the one I am now building. It will ultimately have a huge DB and I want it to stay fast.

Thanks for all the valuable input!

[ergophobe]

Don't get me wrong - 100 queries is TERRIBLE, but common ;-)

I think any page that has under a dozen queries on reasonably sized tables that are indexed intelligently and well-designed should be very fast.

[jatar_k]

the fewer the better is always a good rule of thumb for db calls. Issuing one call with a join will be a lot slower than doing 2 or 3 seperate db queries for the same information.

I agree with ergophobe but also would rather say 6 queries per page rather than 12. That doesn't mean 12 is bad but as ergoophobe pointed out

"reasonably sized tables that are indexed intelligently and well-designed should be very fast"

it depends on so many factors that it is safer to recommend a lower number ;)

You also need to remember that as sites get more traffic or are dealing with larger and larger datasets load will increase. Concurrent users is always something to keep in mind as well.

[ergophobe]

One other thing to say here.

- A single query can be a huge load on the server depending on what it is.

- If you have lots of queries or a few slow ones, you should look into some sort of caching if at all possible.

If the page is not responding to user input, but is just serving up the news of the day, for example, it might take a dozen queries to render the page once, but if you cache it, you might be able to retrieve it with a single query for each subsequent view until it changes.

[4string]

Thanks for the great advice. I really appreciate it!