The main drawback is that you are trading faster request transfers (smaller, compressed server responses) for increased CPU utilization - The server CPU has to compress the response, and that takes time.

The solution for this is to cache any page that has already been requested and compressed, so the server can simply send a pre-compressed response instead of the uncompressed original. The server looks for the compressed version, and if it finds it, it sends it. If not, it fetches the original file from disk (or re-generates it, if the requested page is script-generated), compresses it, sends it, and saves it as a cached version for the next requestor.

So that neatly solves the problem by amortizing the CPU time required to compress the file across many requests.

But, if a site is highly-dynamic, generating different page-content for the same requested URL based on such factors as client User-agent, requestor's IP address (geolocation), time-of-day, etc., then the pre-compress-and-cache solution may not be effective.

So a site like Microsoft, which may present different content to the user depending upon the operating-system identifier in the client HTTP User-agent request header, has to choose between serving uncompressed content, or adding the extra complication of caching multiple responses based up the various factors which cause that content to vary.

You basically have to analyze the factors which might cause your page content to change, and then decide if you can effectively use caching to overcome the additional CPU load of compressing responses. And then, of course, you must test to verify that your analysis was correct.

Jim

Thanks for reply!

Well my site is Classified Ads type where users put Ads for new & used stuff but nothing is published except after approval, so actually nothing will be changed in the site until i activate Ads!

So lets say i can activate Ads every min or something but i set a cron every 30min to make them live!

So how could i use the cashing there?

I understood the technique but how to apply it? Is it something to enable in apache, like enabling cashing in MySQL?

Thanks in advance

If the cache capability is not already a feature of your site's content serving code, you'll need to find a plugin or write it yourself.

Well, i am using "No Cache" headers!

So is that what you are talking about? if i allow it then it would cache the compressed pages automatically or what?

No, the Cache-control header controls client-side caching. To make compression more CPU-efficient, we want to use server-side caching.

As Slade says, if your content-generation script(s) don't handle this already, then you'll have to find an off-the-shelf plug-in, write the code yourself, or hire someone to write code to handle the caching.

If your site is "not very busy" right now, you may not need to bother with it. But if your site gets more popular, you will definitely end up wanting to implement server-side caching whenever possible.

This subject is perhaps more complex than you'd hoped, but less complex than you fear... :)

Your "ad approval" cycle of 30 minutes is good -- You can allow compressed files to be cached on the server, and then have your script(s) delete the appropriate cached files automatically whenever you "release" new approved content (or even do it manually or with a simple periodic cron job).

Take some time and research the issue. This thread has already raised several good aspects of the subject to investigate. ;)

Jim

Thanks a lot for ur input!

I googled and found 2 solutions, but i am not sure if these are what you are talking about!

So can u take a look and give me a suggestion?

www.ilovejackdaniels.com/php/caching-output-in-php/

www.php-accelerator.co.uk/

Thanks in advance

Well, i also found this and i am interested more in it!

[pecl.php.net...]

But i just remembered something which could be a problem! all the website pages can be served in english or arabic based on COOKIE value but same URL.

so www.mysite.com/ad1.htm can be displayed in either Arabic or English with no added value in the URL!

So if my cookie is set now to english but the version in cache was arabic, then i will get the arabic version.. right?

If its true then is there a solution for this b4 i install the cache plugin?

Thanks

Simply cache both language versions, and have the process that serves cached pages look at your cookie (or at the same factor that the script uses (for example, the Accept-Language header) to determine which cached version to serve.

The cached-version files don't have to be named the same as the page -- In fact, no filename ever has to be the same as the URL-path used to locate it. This is what mod_rewrite and many other Apache modules do: They change the "mapping" of URLs to filenames. Just as you have "page" URLs that don't go to 'real' pages, because those pages are created by a script, there need be no relationship between a URL and a filename.

So add -en to the cached English page filenames, and -ar to the Arabic page filenames. You can even cache the different national/regional dialects if your script produces them; Just add -ar-sa, -ar-iq, -ar-eg, -ar-ly, -ar-dz, -ar-ma, -ar-tn, -ar-om, -ar-ye, -ar-sy, -ar-jo, -ar-lb, -ar-kw, -ar-ae, or -ar-bh to the cache filenames as needed -- No problem. :)

We discussed one piece of this compression puzzle [webmasterworld.com] earlier this week. But you are now investigating something I have never done personally, so unless someone else joins this discussion who has detailed experience with this subject, you are in the lead now, and I hope you will post your findings so that others may learn. :)

Jim

I asked my host to install on the VPS PHP Cache plugin so they suggested
"eAccelerator" and i asked them about the arabic and english versions so they replied.......

"I know that eAccelerator wouldn't be effected by that problem, as it doesn't cache the entire PHP script, it just precompiles the PHP source code so it runs faster."

So what do u think?

Responding directly to the title of this thread, there is when the browser is MSIE under certain conditions.

if:

1. The browser is MSIE
   (v6 + v7 tested on Windows XP only)
   
2. The Content-Type is one that MSIE does not recognise
   
3. The filetype is within the local Registry
   (`.pdf', `.zip', whatever)
   
4. The content is encoded

...then MSIE will not de-compress the encoded contents and, naturally, the content will not display.

Changing the file-headers to force a download will fix the situation:

`Content-Type: application/octetstream'
`Content-Disposition: inline; filename=<filename, no quotes>'

Notes:
`octetstream' is specific to MSIE + Opera; `octet-stream' for everyone else.
`<filename, no quotes>' is the entire filename
`inline' is MSIE-specific; `attachment' for everyone else.

I was originally using (by mistake) a Content-Type of `application/force-download'. That was fine with Mozilla, but MSIE was making it's own little decisions and mistakes.

PHP-Accelerator has worked flawlessly for me. However, it is a PHP-speedup device, and has nothing whatsoever to do with the sort of caching that you are talking about.

• PHPA : compile + cache PHP scripts : server-side
  
• eAccelerator : compile + cache PHP scripts : server-side
  
• Cache/Lite (PEAR) : cache page content : server-side
  
• misc output-caching : server-side
  
• `Cache-Control' : html response headers : client-side

Try to get a grip on the differences here, smagdy, because you are beginning to make it difficult to help you.

Yes i figured out that eAccelerator will not do what we r talking about, so i think this would do it! plz tell me if i am right so i just start applying it now.....

www.ilovejackdaniels.com/php/caching-output-in-php/

Thanks in advance