Welcome to WebmasterWorld Guest from 126.96.36.199
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.
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
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. ;)
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?
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. :)
"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?
Changing the file-headers to force a download will fix the situation:
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.