In this place I am trying to compare using Server Side Includes (SSI), Miva script and plain HTML documents with an eye for performance and server load.
HTML / SSI / Miva
As for the performance, the best choice among plain HTML, SSI and MIVA is of course non-parsed HTML. You should always avoid parsing your documents by SSI or Miva when it is not necessary.
The best way is to use different extension for each of the file type, for example the standard ones: .htm for HTML, .shtm for SSI and .mv for Miva. Or if you prefer: .htm for HTML and .html for Miva. If you use one of the .htm/.html extension for Miva scripts, in any case you should avoid using it for plain HTML!
If you ultimately need to keep same extensions for different document types, use the <Directory> and <Files> Apache directives to assign the file type selectively. XbitHack is an interesting alternative for selective SSI calls.
I tested non-parsed, SSI and Miva-parsed documents in a loop. In all three cases I called a simple document with a single line of text without any SSI nor Miva directives. SSI documents loaded about 10% slower then non-parsed and Miva was about 10% slower then SSI. The difference grows with the length of the document, number of directives and number of concurrent calls.
Any parsing means not only more operations the machine has to do before serving the document, it also means higher consumption of resources like memory, file handles, cache, etc. Well, it has almost no effect to the visitor if there are only few concurrent calls to the server, but it can slow down the machine dramatically if certain number of concurrent calls is reached. Especially if the server is short of memory and has to begin to swap it to the disk = significant degradation of the performance follows.
SSI or Miva?
SSI-parser is very simple and it is implemented directly in the server. In contrary Miva is a complicated parser, often running as a CGI application and therefore it consumes much more resources then SSI. In the typical cgi installation it is loaded into the operation memory each time a Miva script is invoked.
The conclusion is to use plain HTML, wherever it is possible. If you need just few simple tricks like including a header, use just SSI and parse only those documents that need the enhanced functionality of Miva.
In many cases you can parse your SSI or Miva pages in advance and store them on the server already as plain HTML documents. You can do it manually off-line or in case of regular changes you periodically regenerate the documents with an automated script.
top
SSI and Miva?
What about combination of both techniques? Yes, it is possible but usually it does not make a lot of sense. It is impossible to let parse the output of a Miva script by SSI. You still can store the output (with MvEXPORT) as a static SHTML file. You can call a Miva document from a SHTM document without bigger problems. I do not see any interest of using this complicated and resource intensive way. Some people reported problems with cookies in Miva scripts called from SHTML documents. I was not able to reproduce the problems.
If, for historical reasons, you want to keep the .shtm extensions on your files, but want to use Miva in those documents, you can simply remove SSI and replace it with Miva.You may encounter some problems - you need a small undocumented trick in the .htaccess:
Options -Includes
Action application/x-httpd-Miva /cgi-bin/miva
AddType application/x-httpd-Miva .mv,.shtml
AddHandler application/x-httpd-Miva .shtml
The trick is in using the same descriptive in the AddHandler directive as in AddType. If you did just AddType and Action, it would not work (in most cases).
top