Zend Config Ini Caching

Question

My Zend application uses 3 ini configuration files with a total of over 200 lines that contain more than 100 instructions. Are these files parsed every request? Some people say that they are (for example, here and here ). If so, is this not a performance issue?

The comments in these links have mixed moods - some say that you should avoid ini config files and do your configuration in PHP, some say that you can use Zend_Cache_Frontend_File, and some say that this is simply not a problem. But, of course, parsing 200 lines of text for each request will quickly become a problem if you expect quite a lot of traffic?

If you recommend using the caching method, can you explain how exactly you implement it?

Answer 1

Yes, they are parsed every time if you do not cache them. It really saves time (I tested it in my own project).

So how do you use Zend_Cache_Frontend_File to cache the ini file? Ok, I can provide you an example. In my project, I have a route.ini file that contains several custom routes:

routes.ini

 routes.showacc.route = "/@show/:city/:id/:type" routes.showacc.type = "Zend_Controller_Router_Route" routes.showacc.defaults.module = default routes.showacc.defaults.controller = accommodation routes.showacc.defaults.action = show routes.showacc.defaults.city = routes.showacc.defaults.type = routes.showacc.defaults.id = routes.showacc.defaults.title = routes.showacc.reqs.id = "\d+" ;and more 

In my Bootstrap.php, I load them using the cache (if possible):

 protected function _initMyRoutes() { $this->bootstrap('frontcontroller'); $front = Zend_Controller_Front::getInstance(); $router = $front->getRouter(); // get cache for config files $cacheManager = $this->bootstrap('cachemanager')->getResource('cachemanager'); $cache = $cacheManager->getCache('configFiles'); $cacheId = 'routesini'; // $t1 = microtime(true); $myRoutes = $cache->load($cacheId); if (!$myRoutes) { // not in cache or route.ini was modified. $myRoutes = new Zend_Config_Ini(APPLICATION_PATH . '/configs/routes.ini'); $cache->save($myRoutes, $cacheId); } // $t2 = microtime(true); // echo ($t2-$t1); // just to check what is time for cache vs no-cache scenerio $router->addConfig($myRoutes, 'routes'); } 

The cache is configured in my application.ini as shown below.

 resources.cachemanager.configFiles.frontend.name = File resources.cachemanager.configFiles.frontend.customFrontendNaming = false resources.cachemanager.configFiles.frontend.options.lifetime = false resources.cachemanager.configFiles.frontend.options.automatic_serialization = true resources.cachemanager.configFiles.frontend.options.master_files[] = APPLICATION_PATH "/configs/routes.ini" resources.cachemanager.configFiles.backend.name = File resources.cachemanager.configFiles.backend.customBackendNaming = false resources.cachemanager.configFiles.backend.options.cache_dir = APPLICATION_PATH "/../cache" resources.cachemanager.configFiles.frontendBackendAutoload = false 

Hope this helps.

Answer 2

If you download a framework like ZF, you download dozens of files with thousands of lines of code. Files must be read for each user and request. On the server side, you have caching with disk controllers, as well as the fact that files should not actually be read from disk every time. Also, memory managers in the operating system track this and provide some caching in memory, so it does not need to be read in memory every time - only from. Then you usually have a database, where more or less the same thing happens, because the database is ultimately stored in a file on your hard drive. The database server reads the file and the same story more or less.

So, would I be worried about a few lines in the configuration file? Of course, not because I need data to run my application. Where it comes from is secondary.

About caching with Zend_Cache. If you have data that is compact and does not require a lot of processing, like files in Zend_Config, you will get saving tiny microseconds. You essentially save the compact format in another compact format; serialized strings that need to be unesterialized again. If you can cache data to avoid accessing the database or providing a whole view, including all data requests with models playing outfits, we are talking about a completely different story.

Answer 3

If you assumed that the PHP file is cached in memory or in the ini file, which is also in memory, you can get performance by converting the ini file to a php file, skipping the Zend_Config_Ini class and the parsing process.

 # public/index.php $cachedConfigFile = APPLICATION_PATH.'/../cache/application.ini.'.APPLICATION_ENV.'.php'; if(!file_exists($cachedConfigFile) || filemtime($cachedConfigFile) < filemtime(APPLICATION_PATH . '/configs/application.ini')) { require_once 'Zend/Config/Ini.php'; $config = new Zend_Config_Ini( APPLICATION_PATH . '/configs/application.ini', APPLICATION_ENV ); file_put_contents($cachedConfigFile, '<?php '.PHP_EOL.'return '.var_export($config->toArray(),true).';' ); } $application = new Zend_Application( APPLICATION_ENV, $cachedConfigFile // originally was APPLICATION_PATH . '/configs/application.ini' ); $application->bootstrap() ->run(); 

I tested with ab. Uncached configuration:

 ab -n 100 -c 100 -t 10 http://localhost/ Requests per second: 45.57 [#/sec] (mean) Time per request: 2194.574 [ms] (mean) Time per request: 21.946 [ms] (mean, across all concurrent requests) Transfer rate: 3374.08 [Kbytes/sec] received 

vs Cached config:

 Requests per second: 55.24 [#/sec] (mean) time per request: 1810.245 [ms] (mean) Time per request: 18.102 [ms] (mean, across all concurrent requests) Transfer rate: 4036.00 [Kbytes/sec] received 

This is 18% better.

Answer 4

According to our friend who created the files:

https://github.com/QualityCase/Mini-Case/blob/master/modules/admin/Bootstrap.php

I found this very useful:

 protected function _initConfig() { if(!$config = $this->_cache->load('config')) { $config = new Zend_Config_Ini(BASE_PATH . '/configs/application.ini'); $config = $config->toArray(); $this->_cache->save($config, 'config'); } Zend_Registry::set('config', $config); }