I am wondering if going from SSI's to either ASP or PHP on my server will help with my CPU-hogging sites on my Raq4i. My sites are huge and changing page extensions would be a huge undertaking, but I'll do it if you all think it would be worth it. Also, which would be better in the longrun, CPU lite wise. ASP or PHP?

Also, the RAM on my Raq is 512 and I'm still getting "The CPU is heavily loaded" messages. (I have several CGI banner scripts going.) It would save me about $50 a month to drop the RAM to 216. Do I dare? Could the scripts possibly crash my server with the RAM so low?

I am wondering if going from SSI's to either ASP or PHP on my server will help with my CPU-hogging sites on my Raq4i.
Well, it's certainly going to be more efficient than the cpu-intensive cgi scripts you're running now.
Also, which would be better in the longrun, CPU lite wise. ASP or PHP?
On a *nix machine, I would certainly recommend php. The Chili!Soft ASP package that comes with the Raq just isn't very good, and as I understand it eats up a fair amount of the CPU itself.
It would save me about $50 a month to drop the RAM to 216. Do I dare? Could the scripts possibly crash my server with the RAM so low?
More is always better. And if the system's resources are used up, it could very well crash your server. But the extra $50 a month for ram seems kind of extreme. Maybe you should find another dedicated provider that will give you the ram you need for a one-time fee.

Banner Scripts
What type of cgi-scripts are you running? PERL?
You may want to look into C/C++ based replacements for any script that is using an interpreted language. I have seen many problems using PERL banner scripts. Many of them have huge problem, memory leaks, high start-up overhead, etc. At the very least, consider running a mod_perl banner script.


We recently replace our webmail interface with a C version instead of the PERL scripts we were using. RAM and cpu loads lightened considerably. Also, the C version is *much* faster. (Estimate 10X faster at least).

Scripting Language
Be carefully when choosing your scripting language. Take a careful look at what content is dynamic and how that content is retrieved. Recently, I read a review (I think in WebTechniques) regarding scripting languages. They covered JSP, ASP, Perl, PHP, Cold Fusion ... Their conclusions are that PERL and PHP do not scale very well but may suit smaller sites -- whereas JSP, ASP, and CF offer more scalability and performance for complex tasks.

You may want to take a look at your page design and make sure that non-dynamic elements are not getting called through dynamic means. I have seen serveral sites where whole subsections have many dynamic components that could be re-worked to prevent database calls, etc.

I wold say that PHP is better than perl. ASP is good, but I am not sure how well it runs on chillSoft ASP. JSP is the best of all.

But all this depends on how those script writers wrote their scripts. A bad scripts will consume lots of system resources no matter what languages it was written in.

Hmm, the question was about SSI compared to PHP/ASP.

Is there a advantage to use PHP instead of SSI for file including and such things?

I'm considering to use PHP instead of SSI, PHP could also do a little bit more, but is this more CPU friendly?

SSI is faster than PHP for the simple stuff
I have seen various reports that for simple includes SSI is slightly faster (5-10%) than PHP. This is for doing simple inlcude statements (include file, include virtual) comapring PHP compiled into apache vs. mod_include compiled into apache. I have not verified this info myself but this has been reported by various people. Also, I do not know if any PHP cache products were used.

Rationale of why SSI is faster than PHP
This makes some sense because every PHP page has to be put through the PHP processor, which probably requires more overhead than the simplisitic SSI processor. So if you are just pulling in header/footers/menus etc, SSI would probably work better. Also, I do not know if apache caches SSI processed pages??? It would be interesting so see how PHP compares to SSI with and without PHP caching.

However, since both approaches are very close in speed, I would suspect that the type of functions would have a significant impact on performance. The only real way to know is to test.

Benchmarking
I believe apache comes with a benchmarking utility called ab (apache benchmark). Before you switch, I would take a example page(s) and use ab to fetch them and monitor the server performance using PHP and using SSI.

RAM usage
Note that apache with PHP consumes more RAM than apache without PHP. So, if you do not need to use PHP at all, then you could eliminate this module.

For more complex tasks, PHP would probably work better, but once again, benchmark to make sure.

SSI is not better than PHP. Not by a long shot here's why:

Technical Detail...
When you activate SSI, what you are telling your server to do is to parse every page that goes through your system and check it for special tags, know as SSI tags. Now, for one or two pages, SSI is great. It allows for you to include one file for multiple pages. However, for a bunch of files, this is CPU UNFriendly. This is because every page that leaves your server has to be checked first, then sent second. Multiply the number of pages that you have (whether they use SSI or not) by the number of times that each page is requested per day and you have the total number of processes that your CPU has to handle BEFORE it even sends the pages to the person requesting it. As you can see, your server will be heavily bogged down.

Now PHP includes (with SSI turned off) is different. This is because PHP includes only work with PHP files. PHP, like Perl, is an interface that gets processed. But unlike Perl, PHP only processes the PHP tags, leaving the HTML alone. Thus, if you are using PHP simply for the include tags, then only the include tag in the PHP file will be parsed by the server. The rest will be sent to the browser. All Non-PHP files will be sent to the browser without ever being parsed. The result is less processing by the CPU and ultimately less hog on the server.

I also recommend that if you are using a RaQ4i, turn off what you are not using. If, for example, you are not using ASP, turn it off. ASP is a huge hog on the server and if you are not using it, it should not be running. Also, if you are running mySQL on the server and are not using it, turn it off as well.

As for the banner programs, I agree with Huck. Perl based banner programs are huge hogs on the system. The coding for the programs are sloppy and require a lot of processing. One of the biggest hogs is Web_Adverts and Adcyle. Even though Adcycle uses mySQL, the CGI is extremely complex. I have crashed my mySQL server serveral times using Adcycle on a site that gets about 300,000 hits a month. Imagine what it could do to a site that gets that much a day!

When you activate SSI, what you are telling your server to do is to parse every page that goes through your system and check it for special tags, know as SSI tags.

Wrong Wrong Wrong ...

Please understand how Apache handles proccessed documents. Apache uses the AddHandler directive to determine how pages that end with certain suffixes are processed. This is true for PHP, CGI-BIN, and SSI.

From the apache docs:

A "handler" is an internal Apache representation of the action to be performed when a file is called. Generally, files have implicit handlers, based on the file type. Normally, all files are simply served by the server, but certain file types are "handled" separately.
Source:http://httpd.apache.org/docs/handler.html#definition

mod_include handles SSI functions for apache. Accordingly, only documents with the extension (e.g. .shtml .shtm) that you have specified in the AddHandler directive will be processed by mod_include for SSI statements. This is no different than the server scanning for PHP files. See the apache docs for more info.

Now PHP includes (with SSI turned off) is different.
....
PHP only processes the PHP tags, leaving the HTML alone. Thus, if you are using PHP simply for the include tags, then only the include tag in the PHP file will be parsed by the server. The rest will be sent to the browser.

No. No. No.

Any file ending in the extension that you have specified in an AddHandler directive (e.g. php, php3) will be handed off to the parser (e.g mod_php) and processed. For PHP, the entire document is parsed by the PHP engine and then passed back to the web server. Of course, the PHP parser only does things to the PHP statements in the file, but this, in general, is no different than how SSI, mod_perl, or cgi-bin works. (The parsers themselves have internal differences). For most parsers, the documents are passed off to the specified handler which returns the code to be passed on by the httpd server to the client. Different parsers interface with the Apache API in different ways, but the overall data processing model is the same.

.htaccess
Now mod_access can take a big bite out of performance. If you have enable mod_access to take advantage of .htaccess protection system, then you will slow down apache. This is because appache has to check for a .htaccess file in every directory. The deeper the directory trees on your server, the more checking that has to be done. If you do not use .htaccess to password protect directories, then you can turn this module off. Also, if you only have a few directories that need to be secured, you can put them under a /pathtowebsite/secure directory and set mod_access to only process directories within and under the secure/ directory tree, thus cutting down on the amount of processing.




I also recommend that if you are using a RaQ4i, turn off what you are not using. If, for example, you are not using ASP, turn it off. ASP is a huge hog on the server and if you are not using it, it should not be running. Also, if you are running mySQL on the server and are not using it, turn it off as well.

Yes Yes Yes
Excellent advise. Not only does this free up resources, but perhaps more importantly, it eliminates any security issues that those services might have.