Geek Answers Handbook

Creating static HTML files from a database

I have a site that is intense enough for the database, so I try to reduce the use of the database where possible. One place I want to do is in every thread of my forum.

Instead of dynamically generating each thread each time it is viewed, I was thinking of creating a static version of each thread that will be overwritten anytime a new post is created. Each stream will be stored in the / html / forum folder, and threads that have not been edited for 3 or more days will be moved to the / html / forum / archive folder (therefore file_exists do not need to search through 5000 html files each time for widely viewed streams )

Here is an example of what the new thread page will look like:

require_once('header.php'); if(file_exists('/html/forum/'.$thread_id.'.html')) { require_once('/html/forum/'.$thread_id.'.html'); } elseif(file_exists('/html/forum/archive/'.$thread_id.'.html')) { require_once('/html/forum/archive/'.$thread_id.'.html'); } else { //display something about how the thread doesn't exist } require_once('footer.php');

The forum is just one example, but I thought about it with most of the pages on my site. Are there any significant disadvantages or advantages of this method for dynamically creating content every time?

Thanks!

+4
source share
2 answers

Using static files like this is not a bad idea at all, but don't worry about the archive subdirectory. Instead, split the cached files into sub-frames using some abstract value, such as the last digit of the stream identifier or the first two characters of the stream identifier hash md5 (). So you get:

 /1/121.html /1/301.html /2/92.html /3/13.html

This will cause the files to be disabled. You may want to go through more levels depending on how the files you expect to have are:

 /2/1/121.html /0/1/301.html /9/2/92.html /1/3/13.html

Alternatively, you can put this static content in something like Memcache - then you don’t have to worry about file names at all, just specify the stream identifier. You can even put content into your SQL database - at least in this case you only run one query from a single row instead of a large join.

+2
source

I would usually stick with dynamically creating pages, because if you have, say, a stream with 10 pages, you will have to catch a lot of events that trigger a cache update. They are not limited to just a new post. You will have to catch all CRUD operations on messages. Imagine a cache update if some of the messages on page 1 are deleted. Moreover, user statistics (total number of messages, online status, etc.) should usually be fresh for viewers. So my vision is that the performance advantage is not worth it.

+3
source

More articles:


All Articles