caching faster?

[Cardale]

If caching is faster then why not just generate html every time a change is made?

[lemmin]

In what context? In the case where a web application is being used by many people and the data is constantly changing, this would be impractical.

[MadTechie]

Caching doesn't always refer to the whole page!

also it doesn't always get written to the disk,

 

also bloating the HDD with a ton of cache will decrease performance,

 

if your pages don't have dynamic data then sure why not!, but then again why not just have a HTML page!

[premiso]

If caching is faster then why not just generate html every time a change is made?

 

Caching is definitely faster, if you have static content. However, as stated above, most content is dynamic and for the benefits it is not worth it to cache every single dynamic page. Now, aside from caching you can send the pages compressed to the browser, such as gzipped which sizes the page down considerably. But yea, if the code is done efficiently and there are not many images on the page you should not notice too much of a difference between a cached page and a non-cached page as most connections (and computers) are way above par for displaying webpages.

[Cardale]

In what instance would caching not be efficent?  What is this problem you speak of?

[Daniel0]

In what instance would caching not be efficent?

 

When the content changes often and realtime updates are necessary.

[premiso]

Ok, lets say you host a blogging website and have 2,000 users who post at least twice a day on the website, so that is 4,000 new posts a day. Each post is stored in a database and you want to cache the html created from the post, either in the DB or on the Harddrive, we will say the harddrive just for this purpose. Each time a post is created a create a new cached entry on the harddrive, in a months time your harddrive will have 120,000 files, in a years time your harddrive will have 7,120,000 new files on it. Now if you want comments on these posts everytime a comment is added you have to re-cache the post or if the user edits their post.

 

So eventually your harddrive has a ton of files on it, that is really unnecessary and can make access times of the harddrive slow down a bit, and not to mention constantly replacing cached pages etc will fragment the harddrive pretty bad. Now let's say you are upgrading to a new server, well copying all those files will be a pain in the butt. So you decide to re-create them on the new server, well that will take some time as well.

 

It just really is not practical for that type of scenario.

 

Now if you are just running your own blog site, when there is maybe 2 posts a day and you rarely edit them, then caching would probably be a good idea, but instead of storing the post in a database why not just create the html file and set the <meta> tags to cache. Why would you need PHP to do that? But if you would rather have it in a database, well you can create the html file then just update it but that kind of defeats the purpose of the database (kind of).

 

But yea, you can debate it all you want, the real and true answer is, do what you think is best. I can give you my opinion on it, but in the end it is what you want to do that matters.

[Cardale]

I appreciate the explanation.  Let say writing to a database is faster and suppose the amount of files you suggest isn't an issue because we have terabyte drives now.  You could save resources by not using a "database"  and just use more space instead.  Is the question just a matter of memory vs. disc space?  Would this cut down on cycles?  Has anyone done any tests for something like this?

[premiso]

we have terabyte drives now. 

 

I do not think space is the issue. With a database most of the database is contained in a handful of files (Each table as a separate file if I am not mistaken for MySQL). So it would definitely cut down on cycles as it is always accessing those few files vs having to locate 1 file among 7 million files and it will also be less fragmented as the same reasoning, a few files is a lot easier to handle the deleting/editing/creating files stored on the server etc which can tend to fragment files...especially with 7 million files. Where as the MySQL database would just grow in size depending on the text (which really is not much for size so that is not an issue) I doubt you would go over a few hundred mb's either way with files or MySQL.

 

Now the other issue is searching, if you wanted to incorporate a search a database will do this so much faster than searching through flat files, as databases have indexes that you can set etc, which make that take an insanely less amount of time.

 

But I would bet it would be much easier on your harddrive storing it all in a database vs storing it in separate files just because it is accessing a few files vs million's of files. As far as proof, no clue if anyone setup a test, I think it is just more or less common sense?

[Cardale]

we have terabyte drives now. 

 

I do not think space is the issue. With a database most of the database is contained in a handful of files (Each table as a separate file if I am not mistaken for MySQL). So it would definitely cut down on cycles as it is always accessing those few files vs having to locate 1 file among 7 million files and it will also be less fragmented as the same reasoning, a few files is a lot easier to handle the deleting/editing/creating files stored on the server etc which can tend to fragment files...especially with 7 million files. Where as the MySQL database would just grow in size depending on the text (which really is not much for size so that is not an issue) I doubt you would go over a few hundred mb's either way with files or MySQL.

 

Now the other issue is searching, if you wanted to incorporate a search a database will do this so much faster than searching through flat files, as databases have indexes that you can set etc, which make that take an insanely less amount of time.

 

But I would bet it would be much easier on your harddrive storing it all in a database vs storing it in separate files just because it is accessing a few files vs million's of files. As far as proof, no clue if anyone setup a test, I think it is just more or less common sense?

 

Well I was thinking more or less something more suited only for web servers.  My understanding or common sense is when including a file only include what you would need.  Breaking your code up into separate files is much faster.  Saying that you would have millions of files all in one place might be how it is done if you included folders which I don't know this is only a thought.  A database is just a special data structure is it not?  A convenience for humans?

[MadTechie]

Okay think about this, you have a page on your site that build a jpeg, the jpeg is a history graph of the companies performance,

Now to build this jpeg, it takes some complex maths and 200 SQL queries (just for a this example) and takes 7 seconds to built it,

and the data changes daily.. Now when the first user browses the page no charge exists so it needs to be built,

BUT if you keep that chart (in cache) then the next visitor can load the page without waiting the extra 7 seconds,

(you could do the same thing, even if it changed hourly) but what if its changed every microsecond.. caching would be kinda pointless.

 

Now just say you had a page that said "Well MadTechie" and the only dynamic info was MadTechie, caching that page would also be pointless as your server would end up with welcome page for every user, and the time it takes to find and load the cache file would be longer that the time it took to echo a single variable, also if the welcome page was updated your need to re-process all the welcome cache pages, which will also take up time,

 

I hope that helps clear things up