With little experience in the caching department, I can only assume there has to be a better way to do this (Any suggestions?):

PHP Code:

<?php // ## Retrieve Persistent Lists

 $persistence = 15; // ## Days to Retain
 $cache_loc = "./cache/active_stuff.php"; // ## Cache Location

 if (file_exists($cache_loc) && (filemtime($cache_loc) < time()+60*60*24*$persistence)) // ## If Cache Exists
        {
            $active_stuff = unserialize(file_get_contents($cache_loc)); // ## Read Cache to Array
         }
 else
        {
            $dbSQL = "SELECT stuff_id, stuff_name, stuff_desc FROM stuff WHERE active = 'Y'"; // ## Prepare Query
            $rs    = mySEL($myHOST, $myDB, $myUSR, $myPWD, $dbSQL); // ## Connect to DB & Run Query
        while ($row = mysql_fetch_row($rs)) // ## Iterate through Results
                {
                    $active_stuff['name'][$row[0]] = $row[1]; // ## Append to Array
                    $active_stuff['desc'][$row[0]] = $row[2]; // ## Append to Array
                }
            file_put_contents($cache_loc, serialize($active_stuff)); // ## Write Array to File
        }
 unset($persistence, $cache_loc); // ## Clean House ?>

I am attempting to reduce my overhead by reducing the number of queries and calculations via caching. The data will be used to populate all manner of form fields and options.

I'm no expert, but I think that the mySQL server would tend to be much faster than reading a file on the server, and also much more reliable.

Really? While I realize this method shifts the work to the web server I would think the serious reduction in the number of queries would reduce the total overhead (??for the mySQL server at least??).

Hmm... what if I stored the serialized arrays in a cache table on the mySQL server?

Hmm... (as I understand it) wouldn't this reduce the network load as well? The database servers (in this case several) are all on different servers, wouldn't the reduction of requests, responses across the network & the reduction in cpu cycles needed to loop through & parse each response be significant savings?

Usually, except when you are starting to have a lot of query sent for a page, caching is not the good answer.

A query can be so badly written, than it will need 4/5 seconds to run.
Of course, caching, in this case, limit the number of time the bad query is fired, but not why it takes so long.
You cure the effects, but not the cause.

I have used a caching mechanism like your for a site I worked on some years ago.
But we where around 8Go of data transfer per days, and around 60 queries per seconds when we implemented the caching mechanism.
We already had optimized the queries by that time.

But otherwise, your caching mechanism looks ok.
You might want to take a look on memcache, as it's especially designed to hold a record in the form [key]=[value] for a time that can be specified.
This let the stored key became invalid after a given time, without the need for you to delete the file from the server.

Thanks for the clarification and the memcache (looks like something I'll definately have to explore).

In this case I think the database (& poor support for odbc) is more at fault than poorly written queries. Unfortunately, one of the databases I'm dealing with is Progress (Be thankful if you haven't had the misfortune of dealing with this beast). What's more the main database in question is poorly designed, fraught with redundancy, and inadequately indexed.

Also, we're dealing with a significant number of queries (at least for our sad little network). Somewhere between 10-30 individual queries per page/request, some with nasty (and unavoidable) joins (which the Progress ODBC driver chokes on).

This is what happens when you take your soapbox racer on the freeway.

Man, you stack up problems here.

1) poorly designed db (I'm taking the indexes in acount)
2) remote server
3) no native drivers

I suppose you don't have the credentials (or the contact) to add the proper indexes on this db...
Not much to do to help in that case, except reduce the number of queries sent to the db, effectively.