JavaScript vs. Server-Side Includes

[Michael Squires (michael)]

We have used (extensively) SSI for three years now (turning it on for
the entire tree). As far as we've seen, the benifits far outweigh \any/
potential performance hits. We've done this with both the NCSA and OMI
servers.

A note on performance - the httpd needs to fetch the file from the file
system and write it out over a network socket - that's its job (and the
performance is dominated by I/O). Adding a wee bit of CPU use to scan
the file for "<!--#" is trivial. If it doesn't find it, you haven't paid
much at all. If it does find it and needs to do an additional I/O (for
example, #include some file), then presumably you are doing it for a
reason and are getting functional value back.

So, we actually use SSI for a number of tasks:
	- #include toolbar.html - to let publishers pull in the standard
toolbar (at fetch time, NOT at publish time) - this gives us a standard
look&feel, plus we can update the function / appearence of the toolbar
in one central place and have that change instantly reflected

	- #include copyright.html (or private.html or ...) - to let
publishers pull in various standard boilerplate at run time - again, it
saves them from the mistakes that cut&paste would bring, plus we can
update (oh, no - legal wants to change the wording on the "company
private" notice - let's update 4,000 pages! - NOT)

	- #echo fsize - if I'm writing a navigation page and referring
to other documents in the site (e.g., powerpoint, word, images, etc),
then I can give the user some sense of size (or last modified) of the
thing that I'm pointing to - note that this might take a bit more time
to process, particularly if there are a lot of them on a page, but if my
user is setting at the end of 28.8 or 14.4 wire and (unknowingly asking
for a 2MB presentation), the price to warn them was well worth it.

In short, we have found the value of SSI in promoting consistancy and
site managablity much higher than any speculative performance hit. Turn
it on for ALL "html" documents (and none of this "htmlx" or "shhtml" or
whatever - it complicates the publisher and user life too much!)



	-----Original Message-----
	From:	John R. Little [SMTP:jrl at acpub.duke.edu]
	Sent:	Thursday, June 26, 1997 3:16 PM
	To:	Multiple recipients of list
	Subject:	Re: JavaScript vs. Server-Side Includes


	On Thu, 26 Jun 1997 15:09:07 -0400 Bill Drew 
	<drewwe at MORRISVILLE.EDU> wrote:

	> The demand on our
	> server is little different before we used SSI.  The benefits
of SSI far
	> outweigh any negatives.
	> 
	> 
	> > ... The difference being that if
	> > I enable SSI for the entire web site, the httpd will search
	> > for imbedded SSIs in each and every file served. 
	> 
	> On our server it only searches files with the extension of
htmlx for
	> SSI, not every file.  You will probably find it to be the case
on most
	> servers that only certain file "types" are processed for SSI.
	> 

	On that note I am mostly interested with the aspect of 
	enabling SSI on the entire htdocs tree.

	To quote a bit more from Chuck Musciano, he writes:

	"For the vast majority of servers, include processing is 
	not expensive. For these servers, I recommend that all 
	HTML files be enabled for includes processing. This way, 
	you can use server-side includes freely in all of your 
	documents without having to use a special suffix."

	That sounds good to me.  It would be nice to use includes 
	in existing files without changing their filename and 
	without worry of degraded server performance. How true is 
	it that fully enabled SSI processing is "not expensive" 
	thus enabling use of SSIs _freely_? 


	--John
	------------------------------------------------------
	  John R. Little       Web Developer/Systems Librarian 
	  Perkins Library * Duke University * Durham, NC       
	  VOICE: (919) 660-5932    Email: john.little at duke.edu 
	              http://www.duke.edu/~jrl/
	------------------------------------------------------