Caching Question

[448191]

I've been reading up on output caching, and after writing a complete caching class, wanting to implement it into my config class, I stumbled on this issue.

If I want to use caching in a CMS, I have to store a copy of every possible uri, for every user that visits my site, if I don't want to risk one client getting fed another clients' cache.

And even if I do that (which would limit the gain from caching to events where a user requests by the same uri more than once - add a bulk of cache on the server - increase server load because of all that extra writing going on), how does the application know some variable data that affect the presentation of a page (like session data, or post input) hasn't changed?

Seems to me caching output is pretty much useless for a CMS. Maybe I can limit the caching to publicly available pages (uri's)... Does that make sense?

Let's see, how would we go about that...

Here's an idea:
1) I check if any 'post' data is present, or the session variable 'user' is set...
2) If none of the above result to true, I use caching.
3) I'll have to separate the output buffering from caching logic, if I am to keep the capability of compressing output using gzip...

What do you guys think?

EDIT: How about 'chunked' caching... Were do I find a tutorial for this? Google's letting me down (there's a first)...

P.S. I'm damn lucky I always use CtrlA-CtrlC before submitting... Almost had to write everything over... Damn Invision "Power" Board!

[448191]

No-one ever dealt with a similar issue? Hard to believe, since performance is always such a big issue.

[448191]

Old thread, but I left coding for a while.. Still haven't figured this one out. (or just "bump"  ;))

[mainewoods]

[size=12pt][color=green]What may be the best page on caching on the web:[/color][/size]

http://www.mnot.net/cache_docs/

-Some things I've learned:

-If you set caching on your pages, the browser and servers beyond you still make there own decisions whether to actually cache the page or not.

-pages that end with a '?' and url passed variables are not likely to be cached by clients or servers

-your best strategy is to cache the graphics that are on the page instead of trying to cache the .php page itself!  Put your rarely changing graphics in a directory by themselves and then use a .htaccess file in that directory to set a long term cache on all the files in that directory.

-that page url I show above also has a link to a web site where you can enter your page url or graphics into and it will make a caching analysis of your web page and graphics and give advice!  If you really want to know about caching, that url I mentioned above is mandatory reading!

[448191]

Can't say I read the info on the site you linked to (yet), but I think your misunderstanding this thread.
For the record, it's about php driven (server-side) caching.

[quote author=mainewoods link=topic=94531.msg402110#msg402110 date=1153677773]
-If you set caching on your pages, the browser and servers beyond you still make there own decisions whether to actually cache the page or not.
[/quote]

Not true for server-side caching. Clients (browsers) have their own cache, indenpendantly. I does not in any way influence the caching on the server. On the server part, as long as output buffering is enabled (I don't know of a way a server admin could disable it), I can write the buffer to file or rdms, feed it to a browser if required, and thus cache.

[quote author=mainewoods link=topic=94531.msg402110#msg402110 date=1153677773]
-pages that end with a '?' and url passed variables are not likely to be cached by clients or servers
[/quote]
It's as likely to be cached on the server as you want it to be, for the reasons above. Client-side, this is probably true.

[quote author=mainewoods link=topic=94531.msg402110#msg402110 date=1153677773]
-your best strategy is to cache the graphics that are on the page instead of trying to cache the .php page itself!  Put your rarely changing graphics in a directory by themselves and then use a .htaccess file in that directory to set a long term cache on all the files in that directory.
[/quote]

Argh. This is not what server-side caching is about. Server-side caching is a way to elude some of the processing nessesary to render a page, thus speeding up the page-generation. I'm already using gzip encoding when available clientside, to reduce the bits to be transferred 'tween client and server. Client-side caching is about reducing the number of bits downloaded by reusing some of those (usually images) already stored.

To summarize, you're more than likely confused with client side "cache-control" (HTTP Headers). Which is an interesting subject, I'll read up on that too when I have the time, but it's not what this thread is about.

[448191]

To better formulate my question (which is probably nessecary, my bad):

What do I and do I not cache on the server in a CMS-context.

[448191]

*bump* cmon peopletjes..

[mainewoods]

What I meant by 'servers' is servers between your server and the client that may or may not do caching for you.  isps for instance do caching of popular pages like google home.  None of those like to cache dynamic urls however and if you try to force it with the cache control headers they probably will just ignore them and not cache it anyways.

-Are you sure that the graphics you use in the page do not add up to more size than the .php page itself?  That is usually the case and especially if you have repeating graphics setting a cache for the graphics can yield substantial results. As well make sure all your .gif and .jpg files are compressed.

-you could use curl() to call your dynamic pages and then use fwrite to write then as static .html files. Could be very messy if you have a lot of pages!  The data on those pages would have to be unchanging.

-if your pages are returning slow then look at the whole page for speed improvements:
-are you using volumous html when you could reduce it by using more css and more effecient html
-compress all graphics, use repeating graphics, set a cache on the graphics directory
-if you have a lot of css, put it in a separate file instead of putting it inline in the head section. do the same with javascript

-trying to cache dynamic pages usually doesn't work well unless the data is now static.  Instead work on controlling the load cost of the objects like graphics in the page returned.  That will speed up page loading and put less of a load on your server.

[448191]

[quote author=mainewoods link=topic=94531.msg402897#msg402897 date=1153780182]
What I meant by 'servers' is servers between your server and the client that may or may not do caching for you.  isps for instance do caching of popular pages like google home.  None of those like to cache dynamic urls however and if you try to force it with the cache control headers they probably will just ignore them and not cache it anyways.
[/quote]
Interesting, I never thought about the servers relaying the info and how they cache. It does however not change the fact that whe're talking about two completely different things:

[b]1)[/b] You're talking about HTTP headers that tell relais and clients what to cache. True, this information can be ignored by them.
The purpose of this type of caching: reduce transfer time, reduce datatraffic, [b]reduce server traffic load[/b].

[b]2) [/b] I'm talking about php driven, server side caching. Your app on the server on which the dynamic pages are created, decides what to recompute, and what to feed from cache.
The purpose of this type of caching: reduce processing time, [b]reduce server processing load[/b].

[quote author=mainewoods link=topic=94531.msg402897#msg402897 date=1153780182]
-Are you sure that the graphics you use in the page do not add up to more size than the .php page itself?  That is usually the case and especially if you have repeating graphics setting a cache for the graphics can yield substantial results. As well make sure all your .gif and .jpg files are compressed.
[/quote]

Probably true for caching type nr 1. Not relevant for nr 2, since no extra processing is involved. Not only are images compressed, All pages are compressed using gzip encoding when available. This compresses a typical page up to only 20%- of it's original size. See
http://nl3.php.net/manual/en/ref.zlib.php if you don't know what I'm talking about.

[quote author=mainewoods link=topic=94531.msg402897#msg402897 date=1153780182]
-you could use curl() to call your dynamic pages and then use fwrite to write then as static .html files. Could be very messy if you have a lot of pages!  The data on those pages would have to be unchanging.
[/quote]

Like I said in my frist post, it is not an option to cache every possible page. Not doable, to many variants.

[quote author=mainewoods link=topic=94531.msg402897#msg402897 date=1153780182]
-if your pages are returning slow then look at the whole page for speed improvements:
-are you using volumous html when you could reduce it by using more css and more effecient html
-compress all graphics, use repeating graphics, set a cache on the graphics directory
-if you have a lot of css, put it in a separate file instead of putting it inline in the head section. do the same with javascript
[/quote]

My pages aren't 'returning' slow, because there's hardly any data to process and virtually no server load. The application is still very much in development. I'm just looking to get any advantage I can get. I'm a perfectionist, I want to make it as fast as it can get.

[quote author=mainewoods link=topic=94531.msg402897#msg402897 date=1153780182]
-trying to cache dynamic pages usually doesn't work well unless the data is now static.[/quote]

That's why I'm thinking about a way of chunked caching. Set different expirarions on different parts of page, so only the parts that actually changed are recomputed.

One of the  reasons why I'm struggling with it, is I don't have a clue how to do this responsably. What I mean by responably: without having the caching logic present a bigger load than the logic I'm avoiding by using caching...  :(

[448191]

Maybe a little more info on the app would help.

I'm building an application that tries to best utilize the servers' and client's capibilities, without compromising compatibilties.

Steps:
[b]1) check if client can handle javascript.[/b]

[u]1a) if true, check if it supports XMLHttpRequest[/u]

[i]1aa) if true, there's not really anything to cache, so disable it.
1ab) if false, enable chunked caching for the static parts of pages.[/i]

[u]1b) if false, enable chunked caching for the static parts of pages, don't rely on javascript.[/u]

[b]2) check if both server and client are gzip enabled[/b]

[u]2a) if true, use gzip encoding, if false don't. ;)[/u]

[b]3) check if client accepts cookies[/b]

[u]3a) if true, use cookies for sessions.

3b) if false, use url encoded sessionid's. When someone registers, ask them if they have static ip.[/u]

[i]3ba) if true, use ip based sessions, if false continue to use url encoded sessionid's[/i]