Dynamic content on a Web site is cool. It keeps people coming back and creates the appearance that there are people behind the scenes actively updating the site to provide new and improved information. However, in the real world, you’ll regret the day you added that SSI include directive in your homepage when you finally do something important enough that Slashdot notices you. Running a CGI script on every single Web hit is a great way to get your Quake game interrupted.
Dynamic content on a Web site is cool. It keeps people coming back and creates the appearance that there are people behind the scenes actively updating the site to provide new and improved information. However, in the real world, you’ll regret the day you added that SSI include directive in your homepage when you finally do something important enough that Slashdot notices you. Running a CGI script on every single Web hit is a great way to get your Quake game interrupted.
So, what do you do? You could set up an include that pulls in a file updated from cron. But how often? Perhaps you get hits during the day but not so many at night, and why waste all the CPU to update a file that won’t be examined for hours? Or, maybe you haven’t quite figured out that arcane crontab syntax yet. Also, you have to master the weirdness of having a script running as you create and update a file that is readable by the Web user. Fun, fun, fun…
Or somewhere in between, you can fire off a CGI hit that has a cache value. If the cache value is recent enough, you pop it up; if it’s too old, you generate the new value, saving that for the next hit. The problem is that this leads to the worst of both worlds, because you must trade off a long cache time with an expensive delay.
So, a while back, I came…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
