|
Posted by David Ross on March 22, 2005, 10:38 am
Please log in for more thread options
Pierre Goiffon wrote:
>
> Alan J. Flavell wrote:
> >>SSI (or the include function of any dynamic code generator like PHP)
> >>is your friend.
> >
> > But it's no friend of cacheability
>
> Why ?
> It don't change a thing for client side caching, and server side a lots
> of servers do implement a caching system in order to optimize SSI includes.
The problem is that an SSI "include" causes the server to alter the
HTML file just as it is being sent. This changes the time-stamp on
the file. Thus, a browser that causes a cached file to be compared
with the server file will always find the server file to be newer.
This results in the cached file being replaced. Therefore, caching
becomes useless; and the server and bandwidth are impacted by
always having to resend the file.
--
David E. Ross
<URL:http://www.rossde.com/>
I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.
|
|
Posted by Fuzzyman on March 24, 2005, 8:32 am
Please log in for more thread options
David Ross wrote:
> Pierre Goiffon wrote:
> >
> > Alan J. Flavell wrote:
> > >>SSI (or the include function of any dynamic code generator like
PHP)
> > >>is your friend.
> > >
> > > But it's no friend of cacheability
> >
> > Why ?
> > It don't change a thing for client side caching, and server side a
lots
> > of servers do implement a caching system in order to optimize SSI
includes.
>
> The problem is that an SSI "include" causes the server to alter the
> HTML file just as it is being sent. This changes the time-stamp on
> the file. Thus, a browser that causes a cached file to be compared
> with the server file will always find the server file to be newer.
> This results in the cached file being replaced. Therefore, caching
> becomes useless; and the server and bandwidth are impacted by
> always having to resend the file.
>
That's not good news. Is it possible to configure the server not to do
this ?
I guess the answer will be server specific... but it's still not good
news :-(
I use SSI a lot.
Regards,
Fuzzy
http://www.voidspace.org.uk/python
> --
>
> David E. Ross
> <URL:http://www.rossde.com/>
>
> I use Mozilla as my Web browser because I want a browser that
> complies with Web standards. See <URL:http://www.mozilla.org/>.
|
|
Posted by Pierre Goiffon on March 25, 2005, 10:35 am
Please log in for more thread options
Fuzzyman wrote:
>>The problem is that an SSI "include" causes the server to alter the
>>HTML file just as it is being sent. This changes the time-stamp on
>>the file. Thus, a browser that causes a cached file to be compared
>>with the server file will always find the server file to be newer.
>>This results in the cached file being replaced. Therefore, caching
>>becomes useless; and the server and bandwidth are impacted by
>>always having to resend the file.
>
> That's not good news. Is it possible to configure the server not to do
> this ?
Almost everytime yes, of course ! As you said, it depends on what
implementation you're using.
But first, you should read the article whose url was given by Alan J
Flavell just a few messages above. Then read your server's documentation
in order to send the appropriates headers. This could be said for all
server side technologies.
|
|
Posted by Alan J. Flavell on March 22, 2005, 11:50 pm
Please log in for more thread options
On Tue, 22 Mar 2005, Pierre Goiffon wrote:
> Alan J. Flavell wrote:
>
> > > SSI (or the include function of any dynamic code generator like
> > > PHP) is your friend.
> >
> > But it's no friend of cacheability
>
> Why ?
I recommend Mark Nottingham's tutorial to get up to speed on the
main features, from which a detailed further discussion might develop.
> It don't change a thing for client side caching,
That depends a great deal on how it's used. But those who have just
discovered it, tend to apply it with happy abandon, without a care for
the cacheability consequences.
> and server side a lots of servers do implement a caching system in
> order to optimize SSI includes.
Perhaps you'd point to some specifics?
> > which can significantly impact server load and impair a site's
> > response if it's used unnecessarily and without taking care over
> > such issues.
>
> I was very surprised to read this !
Oh well...
> Well yes, of course a page with SSI is a little CPU consuming
The CPU consumption is rarely an issue these days. To focus on that
one issue is to miss the point, IMHO.
> It's not like if you were using great pieces of PHP in your pages,
As far as cacheability is concerned, it doesn't matter how much or how
little you use, if you use it at all; but /how/ you deal with the
cacheability implications of what you're doing.
> SSI was used for years and servers do implement it very well
> nowdays.
It still comes, by default, with no cache validators. Even if we use
XBitHack full, we'll only get a last-modified date - no ETag.
> And anyway : CPU isn't the biggest source of costs in a
> hosting service isn't it ?
CPU is not the issue. But if your server gets unnecessarily hammered
by repeat requests for documents that haven't really changed, then it
*does* have implications for server load (think: extra memory usage,
I/O bandwidth, network bandwidth, request latency, and even, to a
small extent, a modicum of CPU).
All of this is also affected in detail by how you configure the
facility, of course. But the broad-brush effects are the same in
principle *whenever* you emit documents which have no cacheability
validator(s) and thus appear to be fresh whenever they're queried.
Then think of it from the user's point of view. Especially if they
have a slow network link, or a ceiling on monthly transfer volume.
So I recommend http://www.mnot.net/cache_docs/
|
|
Posted by Pierre Goiffon on March 23, 2005, 11:06 am
Please log in for more thread options
Alan J. Flavell wrote:
>>>>SSI (or the include function of any dynamic code generator like
>>>>PHP) is your friend.
>>>
>>>But it's no friend of cacheability
>>
>>Why ?
>
> I recommend Mark Nottingham's tutorial
Very good document, thanks very mutch to point it out to me ! I read the
chapter 13 of RFC 2616 when I had to, a few years ago : I'm a developper
and most of the code I write and wrote generates dynamic web pages - so
it was one of the main point I had to learn with Web technologies. And
with a lack of practice, of course, I forgot some of what I learnt
reading the RFC. This document is easy to read, very clear, very
comprehensive !
>>It don't change a thing for client side caching,
>
> That depends a great deal on how it's used.
All right, I see now I didn't totaly understand your first post. I was
assuming you said : with SSI there is no possible client side caching.
But now I understand you just warned on the caching issues you must care
when using SSI - and that it could be used unnecessarily. Damned, my
english is still "far from perfect" :)
You're right, and it's right for almost all the server side technologies
: almost all of them, with their default configuration, makes the server
send caching headers that are not suitable.
Sorry everyone for these useless posts :D Maybe it wouldn't be so
useless for some non native english speakers readers who have an as bad
english level as I have ;o)
|
| Similar Threads | Posted | | 'Web Test Tools List' of 300 tools updated at Softwareqatest.com | May 24, 2006, 11:41 am |
| How can I replace a large image with other large images triggered from small image icons, mouse-overs or whatever??? | July 26, 2004, 1:34 am |
| Advice re debugging techniques | April 17, 2008, 11:16 pm |
| Drop down menu vs scrollable detail rows vs frames techniques | December 19, 2005, 11:49 am |
| worse websites... | August 16, 2005, 1:30 am |
| accessing websites... | November 19, 2008, 10:22 am |
| How are websites hacked and how do you protect against it? | October 5, 2004, 2:16 pm |
| Printing large images | November 5, 2007, 8:08 am |
| Does anyone have any suggestions for synchronizing multiple websites? | March 24, 2008, 11:52 am |
Need to borrow your brain for large | December 6, 2005, 10:43 am |
|
|
|
XML Sitemap