I stopped using the server scope in ColdFusion/Railo (CFML) in Jetendo CMS
All our existing sites were using the server scope for a cached global state and each domain would have a unique CFML application name with a unique application scope.
Drawbacks of using server scope
It has been a bit harder to synchronize changes to the data across all of the sites. I had to do it with separate requests / tracking variables rather then just updating the memory directly.
It made it harder to run multiple copies of the application on a single server.
It seems like competing CFML apps don't use the server scope even if they support multi-tenant functionality.
Now all sites are using the application scope exclusively.
This weekend I was able to move all the data in server scope to be in application scope by rewriting all the related code. The changes are now live across all our sites. This required changing quite a bit of code across over 80 files. In the process of rewriting, I found some redundant memory usage and ways to speed up the application. I also fixed a few bugs. During start-up, the application uses multiple threads to more efficiently load the data into the cache. Now that the sites use less memory, start-up can be a few seconds faster. This will make it easier for developers who adopt our application, Jetendo CMS. Jetendo CMS stores nearly all of its objects and several lookup tables in the application scope to reduce the overhead of the framework and many application features to near zero.
The system now has 1 application name for all sites and the data for each site is stored in a sub-key of the application scope. To make it easier to reference the site data, I assign the struct to the request scope onRequestStart, so that you can access the site specific data with request.app. This is much easier and faster performance compared to writing application.siteStruct[request.zos.globals.id].
Data that is shared between all sites is stored in application.zcore.
In the past, I learned that deeply nested struct lookups are quite a bit slower by writing some simple benchmarks. These new changes reduce the amount of struct lookups in various parts of the application. I've also tested Railo under load, and it seems that the server scope is sometimes up to 18% slower then using the request scope. This is part of why I assign some of the data to the request scope on each request. This is a very small amount of overhead, but every little boost in performance combined adds up to saving more then a few milliseconds per request on a complex page on a busy server.
I also found some of the regular expressions I was using could be made a bit faster, and I rewrote them. These changes make the overhead of Jetendo CMS features smaller then ever. It's very close to "no-framework" performance!
Bookmark & Share
Popular tags on this blogPerformance |
Most Popular Articles
- Mass virtual hosting security tip when using a reverse proxy to connect to other servers
- Solution for MariaDB Field 'xxx' doesn't have a default value
- How to lock Windows immediately upon smart card removal
- Stop using sleep mode with Windows Bitlocker for better security. Learn how to use hibernate in Windows 8.
- Is Google Public DNS actually better then your ISP?
- Pros and Cons of CFML vs PHP and other languages
- Planning a system to visually create responsive data-driven web page layouts & widgets in the Jetendo CMS browser interface
- Run Windows Guest in CentOS 6 Linux Host using Virtualbox 4 via the command line