Page 1 of 2
Best way to persist configuration
Posted: Sat Jan 23, 2010 3:33 pm
by JNettles
I've been refactoring bits of my framework for performance and I've been wondering the best way to handle the application configuration file.
Each application has its own app.xml file with things like connection strings etc. etc. - a typical app has about 30-35 variables that get loaded on every page request and I just factory call it in different parts of the application.
I'm considering sticking the config into the session so I'm not loading and parsing that file on every request. Any suggestions or better ideas for this situation?
Re: Best way to persist configuration
Posted: Sat Jan 23, 2010 4:53 pm
by AbraCadaver
If available to you, memcache might be something to consider. You could stick them in the session, however if the session is file based you are only saving the parsing time of the xml file. Also, if you have 1,000 users online, then you have 1,000 x 35 vars in the session. Maybe cache the results of the processed xml as PHP vars in a file that can be included.
Re: Best way to persist configuration
Posted: Mon Jan 25, 2010 12:04 pm
by JNettles
Unfortunately memcache isn't an option in this case but I like your idea about the include. I'll give it a shot and run some tests.
Re: Best way to persist configuration
Posted: Mon Jan 25, 2010 6:52 pm
by alex.barylski
What good would sticking that into a SESSION do?
You would have to profile that, but personally I use INI which is a simple format (much more than XML or serialied PHP objects). Based on that, I would guess that it's actually faster to parse the INI on every request than serialize an object than unserialize it on the next request. The only benefit in using a SESSION would be to allow users to change their settings on a per session basis, if this is even desirable I don't know.
You would need to actually cache the array in SHMOP, or similar in order to see performance differences. Even then, configuration data is pretty simple and the performance gain would be negligible, IMO. You would be better off finding the greatest bottlenecks and looking at ways to redesign the code to facilitate faster operation.
For instance, dead code or overhead, in my experience account for the most wasted clock cycles, which are usually a result of over ecomplicating the design, over-engineering solutions, etc. Keeping methods and functions small and simple, promotes reuse and minimizes dead code and overhead. I rarely have to refactor algorithms in PHP but minimizing the complexity as a whole makes a huge difference. When I benchmark against similar applications or frameworks, I see differences in the magnitude of 50% in most cases. Sometimes more and even fewer times less, so I am convinced this careful decision during active development pays off dividends in the long term.
Cheers,
Alex
Re: Best way to persist configuration
Posted: Tue Jan 26, 2010 12:58 am
by Christopher
JNettles wrote:I've been refactoring bits of my framework for performance ...
Each application has its own app.xml file ...
... Any suggestions or better ideas for this situation?
A first step would be to not parse an XML file every request. Turn the XML file into a PHP script with everything in an array. You could keep the XML file if you like it and write a build script that generates the PHP config script.
Re: Best way to persist configuration
Posted: Tue Jan 26, 2010 9:59 am
by JNettles
That's the direction I've been leaning.
Re: Best way to persist configuration
Posted: Wed Jan 27, 2010 5:01 pm
by alex.barylski
Have you actually profiled the time it takes to parse XML versus time to parse PHP? Both are much more complicated (and verbose) formats than INI but PHP also has the distinction of supporting a CFG (context free grammar). Which I think would result in slower parsing than a comparable XML file.
It might also depend on how you are parsing the XML file, are you using a SAX parser or DOM? The latter is going to bring a lot of weight to the table, but also comes with it's own advantages, which you have to weigh.
PHP is a nice solution if you have any opcode cache like APC, which would surely speed things up. But in just a raw comparison of XML to PHP, I would think a properly written XML document should parse more quickly as there should be less conditionals during the tokenizing/parsing phase.
Just a thought, I'm interested in hearing opinions, options, experiences, etc...
Cheers,
Alex
Re: Best way to persist configuration
Posted: Wed Jan 27, 2010 8:11 pm
by josh
Data bases are more extensible in the sense that it is easier to change the cardinality of your configuration later (Ex you make a hit new application that lets someone use an extra special form field. Then the users say thats cool can we use 10 of them on the same page each with a different configuration?)
Re: Best way to persist configuration
Posted: Thu Jan 28, 2010 8:34 am
by JNettles
I haven't run speed tests on it yet. For the parser I was using DOM which probably is a bit too fat for what I need to do. This isn't an overly complex document . Basically looks something like this.....
Code: Select all
<Config>
<SDatabase>
<ConnectionString id="devdb1">databaseinfohere</ConnectionString>
<ConnectionString id="qadb1">databaseinfohere</ConnectionString>
<ConnectionString id="proddb1">databaseinfohere</ConnectionString>
<driver id="default">MySQL</driver>
<driver id="db2">DB2</driver>
</SDatabase>
<SWebService>
<ServiceURI id="user_service">http://www.ourdomain.com/webservice.asmx?WSDL</ServiceURI>
<ServiceURI id="client_service">http://www.ourdomain.com/webservice2.asmx?WSDL</ServiceURI>
</SWebService>
<SAuthentication>
<Auth id="global" acl="delegate"/>
</SAuthentication>
<SNamespaces>
<imports namespace="Sanity" />
<imports namespace="Sanity.Text" />
<imports namespace="Sanity.Text.RegEx" />
<imports namespace="Sanity.Web" />
<imports namespace="Sanity.Web.Security" />
<imports namespace="Sanity.Web.Session" />
<imports namespace="Sanity.Web.Services" />
<imports namespace="Sanity.Web.UI" />
<imports namespace="Sanity.Web.UI.Controls" />
<imports namespace="Sanity.DB" />
<imports namespace="Sanity.DB.PDO" />
</SNamespaces>
<SErrors mode="private" log="/errorlog.php" redirect="index.php"/>
</Config>
(There are more fields than this but it gives you the idea - 'Sanity' is the name I've humbly given my framework

)
I like the clarity that an XML document gives me in a situation like this but I'm more interested in raw power at this point - I'll throw together a speed test against an array setup sometime this weekend.
Re: Best way to persist configuration
Posted: Thu Jan 28, 2010 9:09 am
by AbraCadaver
josh wrote:Data bases are more extensible in the sense that it is easier to change the cardinality of your configuration later (Ex you make a hit new application that lets someone use an extra special form field. Then the users say thats cool can we use 10 of them on the same page each with a different configuration?)
Yes, but it's impossible to put some settings in the DB, such as DB connection settings. Also, for small configurations that need to be portable and to get the app up and running after install, file based storage works nicely.
Given the XML that was posted I would go with a straight PHP multidimensional associative array here. At a minimum, if you really want or need an XML file, parse the XML once and then write it out to a multidimensional associative array in a file to be included.
Re: Best way to persist configuration
Posted: Thu Jan 28, 2010 11:04 am
by JNettles
Another question I thought I would ask, as its similar - I was poking around in the Yii framework yesterday and noticed a config file as an array that looked something like this....
Code: Select all
<?php
return array(
'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..',
'name'=>'Yii Test',
// preloading 'log' component
'preload'=>array('log'),
...........
Is this just a matter of including the file (main.php, in this case)? Didn't realize you could straight return a value from a page.
Re: Best way to persist configuration
Posted: Thu Jan 28, 2010 12:23 pm
by AbraCadaver
As well as returning from functions, return ends execution of the current script and returns control to the calling script (i.e. the including script). Also, include/require can return a value. With your config file:
Code: Select all
$config = include 'theconfigfile.php';
The way they are doing it you don't have to know anything about the config file (i.e. what vars it defines, unlike the following common way:
Code: Select all
//theconfigfile.php
$config = array(
'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..',
'name'=>'Yii Test',
// preloading 'log' component
'preload'=>array('log'),
...........
Code: Select all
//main file
include 'theconfigfile.php';
//now to use what was defined in the include, you have to know that the var name is $config
Re: Best way to persist configuration
Posted: Thu Jan 28, 2010 2:33 pm
by josh
AbraCadaver wrote:return ends execution of the current script and returns control to the calling script (i.e. the including script).
Not saying any method is better or worse than any other but another way to achieve the same thing is to have a function in that file and just call that.
Yes you can just return straight from the file.. The reason I don't recommend it though
- global scope
- unrepeatable (what If I want to call it again for example)
Re: Best way to persist configuration
Posted: Thu Jan 28, 2010 3:17 pm
by AbraCadaver
josh wrote:AbraCadaver wrote:return ends execution of the current script and returns control to the calling script (i.e. the including script).
Not saying any method is better or worse than any other but another way to achieve the same thing is to have a function in that file and just call that.
Yes you can just return straight from the file.. The reason I don't recommend it though
- global scope
- unrepeatable (what If I want to call it again for example)
I'm not recommending this method, but several things make it nice:
1. You don't have to know the function name(s)
2. If you use functions you would have to have a different function name for each file
I have normally used functions for this, as well as functions in plugin files for different systems that I have written. I would enforce a naming convention that plugins would be named name.plugin.php and they would have an array $plugin[] that defined the different function names for different tasks. That being said, this returning from the include may alleviate much of that.
I'm not sure what you mean about global scope?
Re: Best way to persist configuration
Posted: Thu Jan 28, 2010 4:02 pm
by JNettles
Why would it return into global scope? If I did a straight include of a variable then yes, it would be global scope. But if I do a $config = include("config.php"); and it returns the array then everything is in $config which you can just factory out as needed. As for doing it again........ factory

. Not only that, you can perform an include more than once.