Yup, it's mostly Apache configuration - exactly what kind of approach depends on whether what you're serving up is dynamic content, static content, and what kind of correspondence you want between the incoming URLs and what's actually sitting in the server's filesystems.

For instance, the most simple thing is to call your .html files .rad files, and all you really need to do for that is make sure that .rad is associated with the appropriate MIME type (text/html or application/xhtml+xml or something else, depending).

Or you can leave them as html files behind the scenes but put in some funky rewriting rules so that Apache maps the incoming .rad URL into a .html, or you can set up a CGI handler for those to actually wrap the static pages with some dynamic content generated by the handler script, or whatever you like. What you can do with mod_rewrite (to re-jig the incoming URLs before handing them off to the internal CGI scripts) plus custom handlers is pretty impressive.

Amish. wrote on Feb 26^th, 2008 at 7:40pm:

Everything costs something; either CPU, memory, disk, bandwidth, latency, or your time. It's just a matter of making the right trade-off amongst those.

Most scripts that produce dynamic content - forums and wikis especially - have an option for caching that dynamic content, so there's a small CPU and latency hit the first time something gets rendered in a while, but then they store that item in a cache (so you're saved future render time, by trading it off against server disk space).

Running static content through a script is a little more expensive than just serving it off disk, but the processing pipeline that webservers like Apache put incoming URLs through is actually quite sophisticated anyway, so can add less additional overhead than you might think to fire it off to a  script interpreter. That's especially true using FastCGI rather than traditional CGI (I don't recall whether you've talked about your Apache configuration in detail to know how you've got that set up).

With FastCGI, the script interpreter process is kept on standby listening to a piece of shared memory, rather than having copies of the CGI handler processes launched on demand that just process one document and exit. The tradeoff there is the memory that one listening process sits in all the time, which your new host have said is the critical resource for their environment.

So, if you have your website configured around one preferred script environment - be it PHP, Python, or Perl - you can minimize the invocation overhead of that one environment a great deal using fast-CGI, but it's best to then stick to just that one script interpreter to get the best use out of the memory it occupies.

Quote:

If you do want to learn this, I would suggest that in addition to whatever else you do, that you grab the DokuWiki source code. While there are no shortage of wikis out there, what distinguishes DokuWiki is that the source code is spectacularly well-written and easy to understand compared to just about everything else. The architecture of the wiki is deliberately kept quite simple (e.g. flat files) so it's mostly pretty easy to see how it does what it does.

Even if you don't install and run it (although it's well worth doing so, and I do happen to like it as a Wiki since it's targeted for developers), it's particularly valuable as a good demonstration of quality PHP code and you can have a lot of fun experimenting with the source code because it's so easy to change.

Quote:

Ah, good ole Geoffrey Rush (in one of his less hammy performances). Anyway, Nigel's a reasonably common name in England, and thus throughout most of the British Commonwealth countries. At one time here at Ghost HQ amongst the developers the duplicate first names were two Nigels and three (!) Andrews.

In my case, it was chosen by my father from the Latin association (mean "dark" or "black") since when I was born I had black hair.