Source Code Cache suggestion
Posted: Tue Nov 08, 2011 11:09 am
Hi All,
Here is a suggestion for future core releases:
While I often read that action files should be separated from the xxx.module.php file and that the xxx.module.php file should be kept small. I have found that within the realm of shared hosting and cmsms (where I assume most sites reside) the above format is not the best from a performance point of view.
Explanation:
Within a shared hosting environment disk access tends to become a bottle-neck / weakest link in the performance chain. As a result the more individual source files that are loaded per framework function the greater the delay on disk read requests will be (generally).
Experience:
I often write small MVC php5 based applications and make full use of the spl autoload functionality. I also fragment my code into class libraries etc for better readability and code maintenance.
Experiment:
I recently tried caching the source code as it was loaded via the php spl_autoload function and linked the resulting combined code file with each framework cmd. Then when the framework receives a request / cmd checked for he existence of a combined source code file for this cmd before attempting to autoload several required source code files.
Result:
Running a php5 mvc framework with code caching improved performance (page load time) by reducing the number of disk reads for framework code files to '1' per framework action + any standard core requirements (also normally combined into one source file).
Suggestion:
Although I am just starting on the road to learning how to develop cmsms modules for 1.10 (lack of docs at present). I can see the potential for caching source code requirements against DoAction's within cmcms.
Perceived Benefits:
Still allows you to maintain a fragmented / file structure for maintenance / readability.
Improve site performance, especially within a shared hosting environment.
Once I become more familiar with the new 1.10 I may attempt some testing, but for now would be interested in other developers thoughts on the above.
Regards.
Jonathan
Here is a suggestion for future core releases:
While I often read that action files should be separated from the xxx.module.php file and that the xxx.module.php file should be kept small. I have found that within the realm of shared hosting and cmsms (where I assume most sites reside) the above format is not the best from a performance point of view.
Explanation:
Within a shared hosting environment disk access tends to become a bottle-neck / weakest link in the performance chain. As a result the more individual source files that are loaded per framework function the greater the delay on disk read requests will be (generally).
Experience:
I often write small MVC php5 based applications and make full use of the spl autoload functionality. I also fragment my code into class libraries etc for better readability and code maintenance.
Experiment:
I recently tried caching the source code as it was loaded via the php spl_autoload function and linked the resulting combined code file with each framework cmd. Then when the framework receives a request / cmd checked for he existence of a combined source code file for this cmd before attempting to autoload several required source code files.
Result:
Running a php5 mvc framework with code caching improved performance (page load time) by reducing the number of disk reads for framework code files to '1' per framework action + any standard core requirements (also normally combined into one source file).
Suggestion:
Although I am just starting on the road to learning how to develop cmsms modules for 1.10 (lack of docs at present). I can see the potential for caching source code requirements against DoAction's within cmcms.
Perceived Benefits:
Still allows you to maintain a fragmented / file structure for maintenance / readability.
Improve site performance, especially within a shared hosting environment.
Once I become more familiar with the new 1.10 I may attempt some testing, but for now would be interested in other developers thoughts on the above.
Regards.
Jonathan