Page 1 of 1

understanding output buffering

Posted: Mon Sep 28, 2009 1:50 am
by cardi777
Hi all. I have been looking into output buffering for speeding up my cms website.

I'm struggling to understand the principles behind it. I read the manual, but i still have questions :)

Say for instance if I have a highly dynamic database driven website where the menu, footer, and content is changing very often on a daily basis. I would have thought that output buffering would cause issues by showing old content instead of the newer. From what I have read, ob doesn't compare data to check for changes, it just does what you tell it. so I think I have misunderstood how it is surposed to work.

Say if I did this...

Code: Select all

<?php
ob_start('ob_gzhandler');
 
all my code here for a dynamic page inc header, content, footer
 
?>
note: i didn't close the ob on purpose

What would that achieve ? Would I need to wrap each dynamic element this like instead...

Code: Select all

<?php
ob_start('ob_gzhandler');
[b]dynamic header code...[/b]
 
ob_start('ob_gzhandler');
[b]dynamic content code...[/b]
ob_end_flush();
  
[b]dynamic footer code...[/b]
ob_end_flush();
?>
Any help would be great!

Cheers,
Doug

Re: understanding output buffering

Posted: Mon Sep 28, 2009 2:16 am
by requinix
I think you're confusing output buffering with caching. They're two completely different concepts.

Re: understanding output buffering

Posted: Mon Sep 28, 2009 6:35 am
by cardi777
i thought something was going on... so whats the difference ?

Re: understanding output buffering

Posted: Mon Sep 28, 2009 10:53 am
by requinix
Output buffering is just a way of not displaying something when normally you would. Like, you can turn on output buffering at the start of your script, let it run, then at the end you can get everything outputted as a string.

Code: Select all

ob_start();
echo "This will not be outputted yet.";
$string = ob_get_contents(); // This will not be outputted yet.
ob_end_clean(); // stop output buffering and clear everything collected
 
echo $string; // now you'll see it
Caching is a way of reusing stuff that was generated previously but isn't quite "old" yet. For example, I could have a PHP script that generates an RSS feed, but since it doesn't change much I cache the feed to a file on the server: if the cached version has expired then it's regenerated, then the script outputs it. Thus if the cache is still good the script doesn't have to recreate the feed every single time it's requested.

Re: understanding output buffering

Posted: Mon Sep 28, 2009 3:46 pm
by peterjwest
In addition to what tasairis said, if you wish to cache files you will need to either store them on a database (e.g. mysql) or as files. Your CMS may support caching, otherwise you'll have to write it yourself.

Saving files would probably be easiest. You'll need to use fopen() to open and save files. Essentially you'll want to save an html file for each section and save the date of the cache somehow. Then you need to update the cache when its out of date.

Re: understanding output buffering

Posted: Mon Sep 28, 2009 4:21 pm
by HavokDelta6
aaaaaaaaaaaaaaaaaaaaaaaaaaaa

Re: understanding output buffering

Posted: Mon Sep 28, 2009 7:20 pm
by cardi777
@ tasairis: I think im a little slow, but can you give me a practical example of when this would be useful?
@ peterjwest:I have been using gCache but its not fitting for all occasions. Why would you write cache to a db? Is that faster or something?
@ HavokDelta6: Thanks for that! Looks particularly useful. But I am still struggling to understand the concept/principle although I understand the code. Its very foreign to me still!

I have one more question a little off topic, but how much faster does a website run if you choose better(optimal) db field types? Is it significant?

Re: understanding output buffering

Posted: Mon Sep 28, 2009 7:29 pm
by Eran
Output buffering gives you better control of output - it allows you to control when and what output is sent (to the browser or otherwise). This is useful when you need to run additional processing on the output before outputting it (most CMS do that).

Optimal database field types can improve performance, but mostly you won't see much difference unless it's very unoptimized. It makes more of a difference for larger databases, where such performance hits become more pronounced.

Unless your website receives heavy traffic or the CMS has some deep performance flaws, caching would probably not make much of a difference. You should look to optimize the client side as there is probably a lot of opportunity for optimization there. http://developer.yahoo.com/performance/rules.html

Posted: Tue Sep 29, 2009 2:12 am
by HavokDelta6
aaaaaaaaaaaaaaaaaaaaa

Re: understanding output buffering

Posted: Tue Sep 29, 2009 10:02 pm
by peterjwest
@ cardi777: For some CMS there will be a lot of processing and many database interactions (e.g. 10-20) per request, if you cache the page in the db you can potentially eliminate most of those, however files may serve you just as well.

I agree with pytrin mostly, caching probably won't help you that much. Get a profiler to find out exactly where you need to optimise. Client side optimisation will help your users but not your site.

Another option would be to take features which change infrequently and only update them probabilistically (e.g. one in ten requests) using a random variable. This lessens the load on each request. Just an idea, I have no idea if any real websites do this :P

Re: understanding output buffering

Posted: Thu Oct 01, 2009 1:50 am
by cardi777
thanks guys !