XbitHack - What's it all about?

Is this method really better than simple .html file parsing?

[damlag]

Hey all.

Well finally configured my SSI's and they work just fine. But I started reading about xbithack and wonder if I should use this method.

As I understand, using XbitHack is better that simply parsing html files, if You want .html extension.

Here's a quote from apache website's article:

"A brief comment about what not to do. You'll occasionally see people recommending that you just tell Apache to parse all .html files for SSI, so that you don't have to mess with .shtml file names. These folks have perhaps not heard about XBitHack. The thing to keep in mind is that, by doing this, you're requiring that Apache read through every single file that it sends out to clients, even if they don't contain any SSI directives. This can slow things down quite a bit and is not a good idea."

Ok so I should use XbitHack. But can someone explain me what exactly XbitHack does then.

If I used simple .html parsing, then apache would scan through all files that end with .shtml and .html. and it will slow things down (as it says above).

So what if I used xbithack. Things will slow down anyway, cause apache will look for files that I have "chmoded" for executing. If I have 100 files and they all contain SSI, then it doesn't matter if I'll use simple parsing or xbitHack method.

Tell me if I'm wrong.

[jdMorgan]

> If I have 100 files and they all contain SSI, then it doesn't matter if I'll use simple parsing or xbitHack method.

If 100% of your html and shtml files contain SSI, then that is true.

XBitHack allows you to "tag" specific files to be parsed fror SSI by using the permission bits instead of by filetype. Therefore, its "granularity" is finer. It also allows you to control the last-modified status of pages which include SSI, by using the XBitHack full option. So it has two possible advantages to balance against the disadvantage of being harder to maintain; You have to remember to set the X bits correctly for each new SSI-containing file, and you may also have to re-check those bits after upating existing files, depending on your server configuration.

There are advantages and disadvantages to both approaches, and only you can really decide which is best for your needs on a particular site.

Jim

[damlag]

Thanx Jim.

Here's what I've read about SSI's :

"Parsing a file for SSI uses more system resources than calling a html file normally and this keeps the server usage to a minimum.

When you change this, every .html and .shtml file called by a browser results in Apache having to check the file for any SSI directives, regardless of whether the file may contain them or not.

The problem with this is that on a server that receives a decent amount of hits, the server usage goes way up and you are wasting resources for no reason. On a small server with a few hits a day you may not notice any difference but as you go up the scale, the server usage gets greater and the time taken for Apache to deliver the pages to the browser gets greater.

If your host enabled this and you personally did not do it, you stuck with .shtml files, you may think that you will not be affected. You could not be more wrong."

So if it really slows the server down, what's the solution?

I know people use cgi modules, php's, other complex build in engines. How they get rid of all this.

Is there any other way to use dynamic content on the site and not to slow server down?

So if I used cgi mod, or php includes, would it make a difference?

As I see, server has to look for all files whether they are parsed or "chmoded". If I wanted to have the same nav. bar on all pages, that means all pages should be with the same extension (cgi, php, shtml, html whatever..). So each time befor sending the data to browser it has to look for all files which have some particular extension?

So isn't there a way to have dynamic content site, with pure .html extensions, which would be opened in browser without telling the server to scan through all particular type files and slowing it down?

[jdMorgan]

> So if I used cgi mod, or php includes, would it make a difference?

All of these solutions have the same problem -- The page must be scanned for included objects. For SSI, the server looks for "<!--#", and for php, it looks for "<?php"

> So isn't there a way to have dynamic content site, with pure .html extensions, which would be opened in browser without telling the server to scan through all particular type files and slowing it down?

Yes, use XBitHack to enable SSI parsing on a per-file basis.

Jim

[damlag]

Jim, so let me get this straight.

So if I use XbitHack method, then I won't slow the server down?

Is that correct?

[jdMorgan]

Sure using XBitHack will slow the server down -- You are asking it to do more work. But it will only have to do more work when a file with SSI is requested. The server has to check the permission bits anyway, before it allows a file to be served, so this overhead is very small.

If you use the AddHandler server-parsed method, then every single file of the specified type(s) will have to be parsed for SSI. By using XBitHack, only those files that you have marked as containing SSI will have to be parsed.

So use AddHandler server-parsed when most or all pages of a specific type have SSI, and use XBitHack when only a few pages have SSI.

We are talking about a usually-very-small performance hit here. As compared to sites built completely on PHP or PERL, or database-driven sites, the SSI parsing overhead is tiny.

The best way to get a feel for this is to try it. If you have a large busy site, then try it on your top three most-popular pages, and see if you notice any performance-related problems. If so, it will be easier to remove the SSI than if you install it site-wide before testing. If your site gets fewer than 100,000 page reads a day, and has no currently-existing performance problems, you probably won't even notice any change.

SSI and server-side scripting are useful technologies. Yes, they incur some "cost" in terms of performance. But this is the trade-off that has been made since the inception of electronic computing; In order to get a beneift, we let the machines do extra repetitive work. That is their purpose.

Jim

[damlag]

Jim, thank You for taking time to answer all my question here.

But plese, answer me the last one, which concerns me at this moment.

Why people say that SSI's can't outperform cgi's and php's. I know, I know... these are old, powerful programming languages.

But if I need only minimum from "dynamic content". Let's say I need only the same navigation bar on ALL pages of my site. No rotating scripts, databases or other fancy stuff. Just minimum, like nav. bar on all pages.

So in this exact situation, is SSI somehow weaker than other pop languages that use dyn. content?

[jdMorgan]

> is SSI somehow weaker than other pop languages

No, because it is built into the server. It does not have as many features, but it's certainly not any slower than those other methods.

Jim

[damlag]

Jim, that's all I needed to know. Thanks a lot for sharing information here.

I have recently found some article about speeding up dynamic content on sites at:

[nwfusion.com...]

maybe Youy'll find it useful.

Ok. Good luck.