Posted by craigmc on April 6, 2011 at 5:01pm
Tagging on to Christefano's presentation, I was curious which takes precedence when setting a variable value: Setting the var value in settings.php or using strongarm (in a feature).
I've tested this in local build, and, as expected, the settings.php $conf array takes precedence over strongarm values.
Comments
ya. settings.php array (a
ya. settings.php array (a file) takes precedence over any module settings (typically in database).
at SandCAMP in January, a list of useful overrides this was started by Senpai : http://drupal.org/node/1021116
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
I'm curious if anyone has any insight
I'm curious if anyone has any insight to what performs better? Where are the $conf overrides cached in the settings.php? I usually shy away from using these extensively in fear of performance but I haven't done testing myself. I guess first, are they cached at all? And second, when does it get excessive to override in this manor? Is overriding 50 strings in settings.php too much?
Settings do get cached
If you check you cache table you will see a 'variable' cid in there with all the values from your settings getting cached in there. As far as I recall from reading in bootstrap.inc, a few things occur:
1) Are the settings cached? If they are, get the cached version.
1a) If they are not, go through the variable table, get the settings, and cache it.
2) Get settings.php to come in. If there are any settings that $conf overrides, use those instead.
So my understanding is that variables set in settings.php do not get cached; Anything in the db would.
As far as performance impact goes from overriding values in settings.php...not really. The arrays and searching through them are fairly fast and certainly a LOT faster than calls to the db. I wouldn't worry about have too many overrides in settings.php.
Like Ashok says, I don't
Like Ashok says, I don't believe anything is cached in the db from settings.php - the point of cache tables is to reduce repeat complex SQL queries and instead store the result of those queries in a special cache table that is a simple db query.
However, webservers were built to serve files. Even a php script like settings.php is faster to process than an index.php?q=foo&bar that then connects to a database, and finally does a query just to get a simple cache. so, no point caching something in a file - since it would actually slow performance.
you might want to investigate additional caching/proxy solutions like memcache or varnish; or something like boost module, which will give you many of the same benefits without as much server configuration.
in general, I'd stay away from too many settings.php overrides. I use them a lot for development, but in production (esp with many people) they can be difficult to debug when unexpected things start occurring (like why a variable isn't changing, that seems like it should and you've forgotten you've hard-coded a value in settings.php).
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
$conf variables vs. Database variables vs. Features strongarm
Further confirmation about what takes precedence here, with an additional note if you're using Features to capture variables in code:
During the bootstrap process, all site variables are loaded via variable_initialize($conf). It follows this logic:
So $conf always wins out, and is never cached in the database.
If you're using Features, its strongarm definitions have a relationship to the database -- you can recreate, override and revert those in code. Features has no awareness of the $conf variables, and those will, again, win out over anything you define in Features.