SSI includes question for you server guys
 

question for you server tech guys..

I'm working on a lot of sites for SE stuff and I'm trying to simplify my work in adding new links for in the future. I was planning on adding my text links on these pages via SSI includes.

Well simply put, will having a lot of pages with SSI includes hurt my server preformance? Also I'll admit I don't know much about .PHP but would I be better off doing the pages in PHP and using PHP includes?

I know my way around windows machines but when it comes to unix servers and server loads and so on I'm clueless.. :helpme

Rename to .php and add the following line for inludes:

<?php require("includefile.txt"); ?>


PHP performance is so fast you shouldn't notice any lag unless you've got like 80 includes per page that are all doing mathematical functions or database queries.

ok that's the direction I was thinking.. No it won't be a lot of includes per page but instead many pages with a few includes.

Hi,

Each time you start a web process, it uses a sizeable chunk of resource overhead.

Every server-side include (SSI) in a page requires a new process (like above) - try to keep the number of SSI's in a given page down to a minimum.

On the other hand, a single SSI can do a pile of grunt work (including HD accesses/writes) without even warming up your box (if it's unix/linux).

I use SSI extensively and without any performance issues (that is, after I distilled 13 SSIs/page down to 2 or 3 :) )

If you need help with SSI strategies, let me know - I'd be happy to help...

-Dino

Dependind on how you call the SSI tag...
Most of my pages have 3-4 calls and I get close to 250k traffic per day on em... doesnt even slow my server down.

The more includes you have the more of a performance hit you will take .. but that performance hit can be almost completely illiminated by using PHP with a compiler cache.

Without a compiler cache I don't think using PHP would be faster than SSI.. but with the compiler cache all the includes would be performed once.. then the PHP script would compiled and cached so all your includes would essentially be run once every so often (when the cache expires) rather than on every single request ... which would virtually illiminate the overhead of having all those includes.

If I did this I assume you are meaning compiling each page in let's say Zend or something similar.. Would the SE engines still be able to crawl the pages if I did that? That is the most imporant goal is to be SE friendly.

I like the idea of doing the pages in PHP becouse I could make the pages a little more dnymanic that way.

However I know almost nothing about PHP, but I can learn what ever I need to.. I'm just trying to do this right from the start, becouse I'm building these pages mostly by hand so I don't want to redo them anytime soon.

:winkwink:

Regarding SE friendliness, even though PHP is a very popular doc type, there still seems to be some 'discrimination' by SEs (visa vi not listing some PHP pages or taking much longer to index them because the are treated as scripts and the spiders go slower on scripts to not overload the site they are visiting).

If most of your pages will be PHP, you may want to add it as the 'handler' for your '.htm/.html' type. This way you can use '.html' extensions (SEs don't have any problems HTML) but the pages (ALL of them - whether they have PHP in them) will be parsed for PHP.

-Dino

A compiler cache is an add-on to PHP.

You don't have to do anything manually except configure the cache once. Basically it interfaces with the Zend engine so that when a script is compiled it saves it and on future requests it uses the pre-copmiled script rather than re-compiling it every time someone requests the document, which is the way it works without the cache (and is why PHP is slower than using a compiled language like C).

Another thing you can do.. if you want to be as SE-friendly as possible and have the benefit of a compiler cache without actually having to install and configure one is what I do on my TGPs..

I run php on the command line to generate static pages. So for example..

$ php -q main.php > index.html

You can set that up with cron so that it runs once per day, or every 5 minutes or whatever you need to keep your site updating when it's supposed to. With this you have pretty much all the benefits of a compiler cache (the script is compiled more often than it would be with a cache but surfers get a static page which is faster than PHP no matter what - even with a cache) and you illiminate any SE un-friendliness that PHP might introduce.

Great idea!

A true HTML page is the best for SE. Even pages with .html extensions which are dynamically created can send HTTP headers which reveal the page was built on the fly (depending on how the server is configured).

-Dino