Best way to persist configuration
Moderator: General Moderators
Best way to persist configuration
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?
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?
- AbraCadaver
- DevNet Master
- Posts: 2572
- Joined: Mon Feb 24, 2003 10:12 am
- Location: The Republic of Texas
- Contact:
Re: Best way to persist configuration
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.
mysql_function(): WARNING: This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQLextension should be used. See also MySQL: choosing an API guide and related FAQ for more information.
Re: Best way to persist configuration
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.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Best way to persist configuration
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
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
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Best way to persist configuration
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.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?
(#10850)
Re: Best way to persist configuration
That's the direction I've been leaning.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Best way to persist configuration
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
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
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
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.....
(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.
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>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.
- AbraCadaver
- DevNet Master
- Posts: 2572
- Joined: Mon Feb 24, 2003 10:12 am
- Location: The Republic of Texas
- Contact:
Re: Best way to persist 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.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?)
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.
mysql_function(): WARNING: This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQLextension should be used. See also MySQL: choosing an API guide and related FAQ for more information.
Re: Best way to persist configuration
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....
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.
Code: Select all
<?php
return array(
'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..',
'name'=>'Yii Test',
// preloading 'log' component
'preload'=>array('log'),
...........
- AbraCadaver
- DevNet Master
- Posts: 2572
- Joined: Mon Feb 24, 2003 10:12 am
- Location: The Republic of Texas
- Contact:
Re: Best way to persist configuration
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:
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
$config = include 'theconfigfile.php';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 $configmysql_function(): WARNING: This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQLextension should be used. See also MySQL: choosing an API guide and related FAQ for more information.
Re: Best way to persist configuration
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.AbraCadaver wrote:return ends execution of the current script and returns control to the calling script (i.e. the including script).
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)
- AbraCadaver
- DevNet Master
- Posts: 2572
- Joined: Mon Feb 24, 2003 10:12 am
- Location: The Republic of Texas
- Contact:
Re: Best way to persist configuration
I'm not recommending this method, but several things make it nice:josh wrote: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.AbraCadaver wrote:return ends execution of the current script and returns control to the calling script (i.e. the including script).
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)
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?
mysql_function(): WARNING: This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQLextension should be used. See also MySQL: choosing an API guide and related FAQ for more information.
Re: Best way to persist configuration
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.