tags:

views:

36

answers:

1

I am currently running too many sites on a server and I don't think the template cache can handle it. But, what really seems to be the biggest drag is when I load my UDF library per site. I say this because whenever I run Fusion Reactor to see where the holdup is, the stacktrace is always sitting on the template that loads the UDF's.

Is the only cure for this more RAM and a higher template cache, or is there a better way?

Maybe I am wrong as well, could there be another issue?

+1  A: 

Before increasing the heap and template cache available, look at a few things.

First, do you actually have more templates in the system than you have template cache? If not, increasing it certainly won't help. Even if you do, if they aren't called often, it probably won't help, but that's harder to measure.

Second, examine whether the server is having difficulty actually loading the UDFs, or if the page is having a problem executing a UDF. Are the functions included on the same template that calls them?

Third, find out why it take so long to load this UDF library. Is it really that big? Can it be split into smaller libraries? Is there one (or more) particular UDF that seems to hang the compile process?

Finally, if there is a large UDF library that must be loaded for each request, I would look at using the Application scope to store it. Include the librar onApplicationStart(), then reference functions as application.myFunction(). This prevents CF from needing to load (and possibly compile) the file at each request.

Ben Doom
Yeah, there are way too many templates on the server. Not all of them get hit often, but from my understanding/stacktraces, every time the requests are hanging it is during a file write operation while hitting the template that loads the udf files. There are about 8 files that comprise the library, so not that many (but there are like 20+ sites). I was mainly speculating that coldfusion has to do extra lifting whilst compiling templates that contain UDFs. The UDFs are all front loaded. Moving them to the application doesn't sound like it would change anything about the template caching though.
Tyler Clendenin
Actually, moving them to the app scope means that they get loaded once at application initialization, which means the templates can then be dumped from the template cache, since they are never recompiled and loaded. They only get reloaded when the app restarts. However, you said it dies on a file write -- could it be a drive failure? Or low disk space? Or needs a defrag?
Ben Doom
10/70 GB free, 42% fragmentation, 84% file fragmentation. Wow, that is horrible. It's been a while since I've worried about fragmentation. This may just be it.
Tyler Clendenin
By the way, I've got a defrag scheduled for tonight, so hopefully tomorrow I will be able to let you know if this was the case.
Tyler Clendenin
Well the defrag kinda worked, but I don't know if it helped. The defrag didn't get all the fragmentation, but it is certainly less. I will have to keep an eye on the server. I also applied this http://kb2.adobe.com/cps/865/cpsid_86589.html to see if it helps.
Tyler Clendenin
On systems with a lot of file writes, causing a lot of fragmentation, I've used Diskeeper (http://www.diskeeper.com/diskeeper/server/performance.aspx). It runs in the background, and seemed to work very well. It also defragged more files than the built-in tools.
Ben Doom