Using PHP to generate static pages and keeping urls good.

[Liquid Fire]

We are in the process of building a new CMS for our websites at work.  One thing we want to be able to do is serve some of our pages as static html pages because even tho our content may be pulled dynamically, it is however not updated that often and serving it is static would really improve performance on those pages.  What systems allow for pages to be delivered dynamically or statically, just to took how it is done.

[dbo]

Couldn't you just do some server side caching? Basically on an update or something generate the markup and store it in a page field. You'd probably also want to have a flag of sorts that you checked. If the flag said page is current you automatically return the markup, if the flag says somethings been updated you'd then run the code to generate it dynamically.

 

I'm not sure on a system that does this offhand. I think the above method would work fairly well and be pretty easy to implement. Whatever you do I would strongly suggest maintaining some HTML files independent of the rest of your data.

[Liquid Fire]

The reason for create file html files is to relieve the issue with mod rewrites.  One idea that was thrown out was create file html files and store the html file url and the mvc url.  if the mvc url is trying to be accessed, it will go to a function that would redirect to the 404 page but before the redirect it would search to see if the mvc url is linked to a flat file url and if so it will redirect to the html file and then update the link the user clicked to change to the flat html file url, which would basically correct dirt(MVC) urls to clean(static) urls.  what is your opinion on this solution, it would be harder to implement that what you suggested i think.

 

I am also a little confused on your suggestion.  you say do server side caching and then your say store the markup in a database, wouldn't it be one or the other and not both.

[dbo]

I guess I was suggesting to emulate your own type of cache.

 

Do whatever you would like by I personally would have to have a damn good reason to want to maintain two different code sets, which is effectively what you're doing when  you maintain a dynamic and a static version. It can turn into a maintenance nightmare very quickly. Forget to update one, and your files get out of sync. Depending on the nature of the data this could be damaging, but just the overall headache of doing twice the work. Then there's the whole issue of growth/expansion of this feature, or someone new taking it over.

 

Blah blah blah.

 

Databases are created to eliminate redundancy in data. Sure CMS makes creating/maintaining sites easier, but their true power is in separating content from design and being able to deliver the same set of content to multiple locations. You just seem to be breaking a lot of rules in order to provide very little benefit, but a whole lot of headache.

[Liquid Fire]

I would agree, I would like to do it in a way where i don't have to maintain a static .html file.  I have been investigating the speed of out site and it seems to be more a loading .js, .css, and image than load the html.  I guess the issue with your way is that i still need to do mod rewrites which for me personally i rather have mod rewrites that maintain the static html pages.

[dbo]

You'll have to load the js and css regardless though... or am I missing something?

 

I don't know how you have your CMS setup, but I don't know that you would -HAVE- to use mod rewrites at all. Are you just using it to have smart URLs and all that fancy crap?

 

In the CMS we use at work we don't use mod rewrite at all. The thing I like about this is that we don't have to marry ourselves to apache. I like apache a lot and host about everything on it, but I don't want to create that dependency unless I have to.

 

If we need smart URLs for something we can just create a new directory such as "about" and then set up a couple variables inside of an index.php, it'd be something like this:

 

$root_path = "../";
$section = 5; //About main section
$page = 10; //Page section

include $root_path . "common.php";

 

I'm not the one who built this CMS and it certainly has its pros and cons, but we can get pretty URLs without mod rewrite.

 

Here's some pseudo code for my proposed system.

 

<?php

SELECT pagestatus, pagecontent FROM page WHERE page = $page

if( $row['pagestatus'] == "current" )
{
   echo $row['pagecontent'];
}
else
{
   QUERY THE DB 15 TIMES, CALL A COUPLE DIFFERENT VIEWS TO DYNAMICALLY
   CREATE THE PAGE, AND THEN OUTPUT IT
}

?>

 

Essentially if the page is current you immediately return the static HTML that would be rendered anyways, without the overhead of the php code, processing, and multiple queries.

[dbo]

The part that gets tricky with doing it this way, to have a truly effective system you're probably going to need some behind the scenes logic that keeps a running track of what fields the current page has a dependency on. If you've got a page that is created off of a WYSIWYG it's not too hard to change the status flag when the WYSIWYG content changes. However, if you've got a page that is generated off of data across 15 tables, you need to change that status flag even if data in 1 of those tables changes.

 

I dunno, there are definitely solutions to your problem I'd suggest doing some performance/load testing and benchmarking your results. I imagine you'd probably have to have a site that's getting slammed pretty hard to justify doing anything.

[Liquid Fire]

Well we are using a <MVC framework(that i built) where we have 1 point of entry, the index.php in the root directory.  so the contact us page would be www.example.com/index.php/site/contact_us or www.example.com/index.php/site/about the issue comes into play when i have stuff the required an id like www.example.com/index.php/destination/details/1 where 1 is the id of the destinations database table.

 

When i say .js, .css, and images, doing something like gzipping them or what not might increase speed as well.

 

I am not sure how much speed improvements we are going to get since when I look at the NET portion of firebug, it looks like 75-90 percent of load time it css, js, and images.

[dave420]

I'd suggest to get XDebug installed on your server and then take a look at where your scripts are taking the longest, and then seeing what can be improved to bring those times down.

 

If you're repeatedly generating (frying) content when serving a static (baked) file would suffice, then it's worth looking in to seeing if you can bake the currently-fried pages in an efficient manner, paying attention to knowing when the cache is stale, and re-generating it.

 

Of course all of this depends highly on the work your site is performing, which is why I'd suggest profiling the performance to see if it's worth caching, and how to go about that sensibly.

[dbo]

You're the first person I've ever heard say baked/fried.

 

That being said, I still stand firm in my belief that maintaining two code sets is jackassery

[laffin]

Reason to use a cache system.

 

depending on the information, cache updates is the question.

 

 

[Liquid Fire]

yea, caching system is another good idea to help and as far as i know easy to use(you just set it up and it will cache files and know when to file have been updated automatically, what is the caching system php in going to include by default in PHP6?

[trq]

what is the caching system php in going to include by default in PHP6?

 

I think your thinking of an opcode cache, (which I believe may eventually be included in php6) completely different kettle of fish to simple server-side caching.

 

Server-side caching is say you have a request that comes into your mvc via /foo/bar/1. From this request you produce a response....

 

<html>
  <head><title>foo - bar</title></head>
  <body>
    <p>this is article 1</p>
  </body>
</html>

 

If you had a caching system in place and caching was enabled for this request you would write this response to a static file in /cache/foo/bar/1

 

Now, once again back in your mvc you get another request for /foo/bar/1, before you execute the chain of events that will dynamicly produce the same result as last time you run a check on the cache to see if the response already exists. If it does, you can skip the entire generation process and simply return the static response.

 

Its quite a simple concept. The trick is figuring out what parts should be cached, how long the cached content remains valid and how your going to check the cached content is valid or not.

[Liquid Fire]

I am still not quite sure if server side caching would help is it would be a bit of work to implement a cache system to know when you updates itself when something is change because there are a number fo table to could effect one page.  opcode caching should help a little and it maintains itself(which is much easier than create server side caching).

[dbo]

Do some benchmarking.

 

Copy some of the generated HTML and save it as an HTML file. Then do some comparisons on load times between the page being rendered and returning the raw HTML. Post some results for us to look at. Should be big fun

[Liquid Fire]

I am going to install xdebug and test how that works.

[trq]

I'm not sure how that is related to caching, or your original question.

[Liquid Fire]

well our site it slow and we wanted to implement caching.  I am just think that it caching my not help us as much as we think and i rather test to see in the php code to generate the html it really so because if it is not i don't want to waste time building this system and only have it save us .5 seconds.

[dbo]

Maybe you need to use MTC instead of MVC

 

I'm still doing some playing, but I think a theming system might work out nicely. I wrote up a basic one last night, which could be extended to do some caching pretty easily.