correct if i'm wrong, but a each time the browser has to make a call on the server (i.e. for javascript, css, img, or in this case ssi) this slows the loading of the page by a bit.
if i used loads of SSI, would that noticeably slow down the loading of a pge, cos the browser would have to make so many calls on the server to display the SSI?
in this case loads probably means 10 to a page?
------------
AND:
------------
i added the .html ending to be parsed, so that i don't have to rename all my docs (and have them reindexed - thanking you mivox) but i have read that this means that each and every .html page will be automatically parsed, regardless of SSI use or not.
we have a high traffic site (70 GB month in high season) on a stand alone cobalt raq4 with 512 ram. this is the only high traffic site we use on this server.
will this cause excessive server-load?
many, many thanks for this convoluted question :)
At a guess, it would be totallly dependent on disk seeks, where each include would require the hard drive to physically find the file that you are requesting PHP to include.
I imagine that disk seeks, the size of the includes, their file name and how often they are included are the factors involved, though I look forward to the heavy weight answer.
I would assume on the grand scheme of things that you as long as your use of includes is considerate then there won't be too much of a delay to worry about.
added the .html ending to be parsed
Since you have just set this up have you noticed any differences? My server is set up the same way and I haven't had any problems. I don't forsee a problem.
SSI
The key, in my experience, is not to nest includes if you can help it. I often use five per page and it does not cause noticable slow downs in page load. I have also worked on sites where the included file included another and that file included another etc. This does cause slow downs and for each extra included file it gets obviously worse.
So if you can stay away from including files inside included files then you should be OK.
whether the server is noticeably faster / slower - doh! - of course! i added the parsing info to the htaccess 4 days ago...
...so conclusion is no, i don't think the site is now slower ;)
so simply best to keep the includes one level deep and not use too many
:) - thanks both of you!
hi brett,
i am interested in using ssi for
a) ease of page maintenance
b) make use of browser caching for certain bits on page which are always same
c) ease of updating.
in an ideal world i'd like a cms, but am a novice with php et al, so ssi and css appears to be a nice solution to make the site easier to maintain and change if necessary.
i don't intend to use things like last_modified, http_referrer, date, etc
we have a fast site anyway, and there is only muggins here to edit and maintain it most of the time, so anything which can speed up my work is gold dust ;) even if there is a minimal trade off with speed. and i'll be honest and say i have not noticed any sort of speed drop since i added the .html and .htm files to be parsed for ssi.
how can htaccess magic help with a) to c)?
cheers
sounds like pretty good software
:)
If you use SSI on pages of 50k or more, then I'd expect to see some noticeable difference, but not before that. I also don't see why including a dozen files recursively would slow down the process significantly more than including the same dozen files on one level. If the system needs to fetch them all from disk, then that is a sequential process in any case, that can't be sped up. The time required to parse some additional (short) files is neglectible in comparison.
What I do for easy site management is the following:
<html>
<head>
<title>a document</title>
<!--#include virtual="meta.html"-->
</head>
<body>
<!--#include virtual="head.html"-->
...actual page content...
<!--#include virtual="foot.html"-->
</body>
</html>
Then I have those three files "meta.html", "head.html", and "foot.html" in every directory. This allows me to include both global as well as section specific stuff from there.
* Meta.html will include global meta tags, CSS and Javascript references, and sometimes a few local styles or keywords etc.
* Head.html can include either a global header template, or a section specific variation thereof. If you use a table based layout, then it will also include the top half of that table, up to opening the main content <td>.
* Foot.html includes the end of the layout table down from closing the main content </td>, and any global or local navigational elements.
Which part is actually included where is of course not cast in stone. You might just as well include the navigation before the page content, or distribute it in other ways, and you will open and close the main content <div> instead of the table for a CSS based layout. The main purpose of such a setup is that you can completely seperate the actual content from the way it is presented in the pages sent to the visitor.
You can actually load each page from a file without the includes, and it will simply present the content without any decoration, and it will still validate that way (assuming the complete setup validates, anyway). You can send the lightweight content pages to other people by e-mail, or you can syndicate your content and someone else can wrap their own layout around it without making any changes to the file.
If you let other people edit your content, then you don't need to worry about them messing with your navigation. Just tell them to leave those three "comments" intact, and you can just send their files to the server without any worries.
b) make use of browser caching for certain bits on page which are always same
SSI happens on the server, so the browser will always see the completed page after the includes have been added. There's no way for the browser to cache partial content.
how can htaccess magic help with a) to c)?
I'm afraid I don't quite see this either. Somehow I suspect that Brett is talking about using SSI to accomplish things that it wasn't really designed for.
each and every .html page will be automatically parsed, regardless of SSI use or not
To enable SSI parsing selectively set the XBitHack [httpd.apache.org] directive to on (instead of having AddHandler server-parsed .html [httpd.apache.org]) in your .htaccess file and make the files that need SSI parsing executable.
Andreas
...each time the browser has to make a call on the server (i.e. for javascript, css, img, or in this case ssi)
cos [sic] the browser would have to make so many calls on the server
rgarding the wrongly described browser caching. isn't there a speed benefit from using ssi, 'cos the same bit of included text / code is repeated - meaning doesn't have to be loaded again?
that way only the 'new bits' of the page are loaded?
many thanks all
