I'm developing some sites to put on a dedicated server, but as I do so, I'm trying to come up with a framework that will allow me to scale to multiple servers with minimum effort and downtime as traffic/use grows (at least until I need more than 4 or 5 servers).

At the doc root of each domain, I'm planning to place thisfile.php with the following contents (or something similar).

<?php

$w1 = "tik.com"; // primary html server
$w2 = "/graphics/"; // graphics server alias
$w3 = "/cgi-bin/"; // remote script server alias
$w4 = "db.tik.com"; // database server alias

?>

(BTW - I do not own tik.com, it's just for demonstration purposes)

In the standard headers of every script or html page on my site, I will have "include_once('/thisfile.php');". When I want to refer to them in html I use: <a href="<?php echo $w1; ?>...">. If I need to refer to them in any scripts, the variables are available via include as well.

If I move graphics to a new server, I just change $w2 in thisfile.php to "graphics[dot]tik.com/" (the lack of the "http" and the use of [dot] are because the system says I'm too new to post a URL - sheesh).

Now My Questions:

1: Is there a more efficient way to do this? Is it possible to cache just those w1, w2, w3 strings so they're read from memory instead of requiring an extra disk read every time? Every caching module whose docs I've read seem to be for caching output itself rather than caching code.

2: Or would it be better to just hardcode the calls, then use Apache's mod_rewrite to send calls to /graphics/ to graphics[dot]tik.com?

Thanks,

Greg

PHP does not have a persistent memory presence at all. This is one of the major advantages of using JSP, ASP or any of the more powerful web programming frameworks: you can store data in memory between requests. As such, any persistence in PHP is achieved by using file or DB I/O. PHP's sessions, for example, are by default implemented using files. In any case, I wouldn't be so concerned about performance with this; file I/O time will be infintessimal compared to run time on all by the most trivial (and useless) of scripts, especially if you're using a database. In short, I'd say it's not an issue you need to be concerned about.

Mod rewrite isn't a solution to this as you seem to suggest, I don't think. It is merely for 'prettyifying' local URLs, and can't send requests to a remote server as far as I know. You'd want to use something like the RedirectMatch directive to achieve that. In any case, I think either of these solutions would actually cost significantly more CPU time than just storing the configuration in a file and writing it out.

Keep in mind that for each request for an item on your web server, a great many files are checked for, opened, scanned and parsed. The entire tree is scanned looking for any existing .htaccess files. All of your PHP includes are loaded and parsed. PHP sessions will be read or created, if you use them. Countless other things are likely going on as well -- the OS is designed to work this way, and even the largest of projects rely on these features, there's no reason to circumvent them for some perception that it might get you an increase in speed.

Write your code, get it working, and then optimize where it counts. A great many 'optimizations' end up costing you in performance. Write elegant, readable, flexible code and if you need speed you can tune the slow parts of it later when you know what they are. This won't be one of them.

Pretty much what he said. You can use mmcache to save some parsing overhead but, if you're down to counting syscalls for performance tweaks, it's time to pry open the purse and upgrade or add a box.