Here’s my scenario:
I’m reworking a legacy CF website which largely consists of a few large .cfm files that contain functions that are cfincluded into each page request so that each component rendering data/views for each section of the website can access any function necessary. Each of these functions .cfm files is thousands of lines of code.
I’m currently reworking this website in more of an MVC type architecture. As part of this, I’m breaking apart these huge .cfm files and converting them to like functionality grouped .cfcs. These cfcs are simply data access singletons. Because of this, I’m loading them into the application scope on application start. Each section of the website is calling cfc methods to get data. Some of our site pages are rather large, and we’re getting data from many cfcs for a single page (think modern long page website with lots of data).
Here’s my problem. The new architecture feels much more maintainable, however, and this surprises me, the performance (at least in development) is worse to the old architecture. For some of the largest pages, I’m getting speeds 50% slower in the new setup. I realize there are many variables here, one of which is the fact that the application scope is significantly heavier under the new architecture, but not too large (460Kb). Another factor is that where there used to be fewer files needed to build a page request, there are 3-4 times more involved due to splitting things apart. The speeds I’m talking are .40 seconds vs .80 seconds. Both very fast, but why is my performance suffering so much?
You could cache some .cfc-files in you Application/Session-Scope. The Lucee Application Server could inspect the files only one. If you want to rebuild the application, I would suggest that you have a look at CFWheels. If you have further performance issues, maybe the Fusion Reactor could help you to understand and find the bottle neck.
Thanks for the reply. I probably didn’t make it clear, but I am caching my cfcs into the application scope. I have used CFWheels, and it is is a good tool, however I have opted to not use it for this particular project.
Your advice to use Fusion Reactor is probably where I need to go next. Thank you.
I would turn on all debugging and ensure debug output is turned on for the pages you are requesting and check the timings. This should give you a clear indication of where the slow down is occurring and I would also check implicit variable access to make sure variables are scoped correctly. I have seen dramatic performance increases by scoping everything.
Thanks for the suggestions. I’ve been working through the debug information. I’m not fully in control of the development box that I build on, and something seems to have changed, because my speeds are now equal to or faster than the old setup, so that’s great.
I noticed that implicit variable access is very high. The old setup has over 600, the new is down to just over 400, so an improvement, but a long way to go. I didn’t know that it could have such a big impact on performance, I’ll have to spend some time working through that.
Don’t worry too much about the implicit variable access! If you would fix it very very well, you could maybe save between 0.1% and 1% on the total processing time. If you are in it for the processing time, then focus on queries and code routines, not the implicit variable access.