Fabio -- Top-posting, as otherwise I fear my comments will get lost.
I'd already been thinking along these lines for ZF2. My thought there was to put this into Zend_Config (as you note already), so that we could rely on it anywhere we utilize a config file. If we go that route, we need to ensure it functions across all adapters -- XML, INI, JSON, and YAML. I think the idea has a ton of merit; could you post this to the zf-contributors list, and also sign and send in a CLA so that we can either get this (or a more generalized solution) into ZF2 or a future ZF 1 release? -- Fabio Napoleoni <[email protected]> wrote (on Friday, 01 April 2011, 06:43 PM -0500): > I'm working on an application which uses 6 database, one per language, and > I'm using multidb configuration to maintain different configurations. By > doing that the application.ini file grows a lot, so I was thinking that is > not so smart to reload the entire application.ini for each request. > > I wrote a Zend_Application replacement which caches the content of the > configuration file, code and unit tests available here: > https://github.com/fabn/zle/ the class is Zle_Application > > I ran some benchmark profiling the following snippet of code and also with > ab tool in the app mentioned above and these are the results > > Profiling this code using in turn both Zend_Application and Zle_Application > > for ($i = 0; $i < 30; $i++) { > // Create application, bootstrap, and run > $application = new Zle_Application(APPLICATION_ENV, > APPLICATION_PATH . '/configs/application.ini'); > $application->bootstrap(); > unset($application); > } > > I obtain these results > > http://img841.imageshack.us/i/zle.png/ > http://img33.imageshack.us/i/zend.png/ > > Using apache benchmark tool on the home page of the test application gives > me the following > > With Zle: > > Concurrency Level: 30 > Time taken for tests: 22.006 seconds > Complete requests: 500 > Failed requests: 0 > Write errors: 0 > Total transferred: 3231500 bytes > HTML transferred: 3108000 bytes > Requests per second: 22.72 [#/sec] (mean) > Time per request: 1320.338 [ms] (mean) > Time per request: 44.011 [ms] (mean, across all concurrent requests) > Transfer rate: 143.41 [Kbytes/sec] received > > With Zend > > Concurrency Level: 30 > Time taken for tests: 25.989 seconds > Complete requests: 500 > Failed requests: 0 > Write errors: 0 > Total transferred: 3231500 bytes > HTML transferred: 3108000 bytes > Requests per second: 19.24 [#/sec] (mean) > Time per request: 1559.311 [ms] (mean) > Time per request: 51.977 [ms] (mean, across all concurrent requests) > Transfer rate: 121.43 [Kbytes/sec] received > > Tests shows that my class is about 16% faster than Zend_Application. > > I've also ran some test with memcached with the same snippet as above and > it's even better here are the results > > dev:/tmp/zle# time php bench-zle.php > > real 0m1.422s > user 0m1.224s > sys 0m0.148s > dev:/tmp/zle# time php bench-zend.php > > real 0m1.849s > user 0m1.776s > sys 0m0.072s > > Used code is the same as before, this time with 300 iteration, > Zle_Application constructor is 24% faster than Zend one > > I don't see any drawback in doing this. > > Any thoughts? > > I was thinking that a similar approach could be implemented directly in the > Zend_Config class in a transparent way, by replacing code in Zend_Config_Ini > and Zend_Config_Xml constructor. What do you think about that? > > > -- > View this message in context: > http://zend-framework-community.634137.n4.nabble.com/Using-cache-for-application-config-file-tp3421394p3421394.html > Sent from the Zend Framework mailing list archive at Nabble.com. > > -- > List: [email protected] > Info: http://framework.zend.com/archives > Unsubscribe: [email protected] > > -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- List: [email protected] Info: http://framework.zend.com/archives Unsubscribe: [email protected]
