I ran across this JVM configuration on a server recently. I should note that the server in question was having some issues, so this is not an endorsement of this approach. I simply had not seen this sort of configuration on a Coldfusion server before. Here are the JVM arguments:
Testing Gurus like Dave Watts and Robi Sen will tell you that iterative tests are only interesting in a passing academic sort of way. Indeed if you are testing a real world application don't bother setting up a fancy-pants loop with 50,000 iterations to see if you should use "IS" or "EQ". If you are going to test then take the time to test real world operations in your application. But while we are on the subject of iterative tests I got to pondering what goes on under the hood. For example, what happens when you do "var1 IS var2" in a CFIF.
Read More
Muse Reader Asks:
We have a client variables database that is currently storing over 1.5 million records. In the Coldfusion Administrator, client variables are set to purge every 90 days. I was thinking of purging every 7 to 30 days to reduce the number of database entries and hopefully improve performance. What are my options?
It's a good question. Performance depends on many thing including hardware, traffic, tuning, and capacity. Still, 1.5 million rows is a large table and as you might imagine it will perform less ably than a table with just a few hundred thousand rows. Let’s talk about these variables and how they are used.
Read More
I have a client with a file intensive application. It allows users to upload images and manage galleries. It's very slick and uses the flash uploader to accomplish multiple file uploads. He was having performance problems with the uploader. The flash uploader is a nifty way to upload a wheel-barrow full of files in a single operation. You can even check for things like file size and type in advance instead of waiting for the whole file to arrive on the server.
What we began to notice is that some requests took longer than others, a lot longer. I, being the expert troubleshooter that I am, naturally thought it was file sizes. I assumed that requests for a 2 meg file upload naturally took longer than requests that handled files of 200k. When we looked closer, however, it turns out that was not the case. A much more sinister culprit was lurking.
Read More
I just read this fabulous post from Mike Schierberl's blog on Variables Scope Leaking and I thought I would pass it on as a good read. To summarize, it is a common practice to create a component into the application scope and include an "init()" type function in it that returns an instance of itself. For example you might have an "employee" component who's "init()" function takes an employee id as an argument and returns an instance of "employee" populated with user data. That's pretty standard. If you return this new populated instance into the variables scope you would expect the variable to be discarded at the end of the request. Mike's post shows that this does not happen as expected. Because the variables returned are referenced (as apposed to "by value") they persist beyond the request termination.
As a fix you can add structClear(variables) to the end of your request - in the onRequestEnd() function for example. I can't explain it better than Mike. He includes a sample and a flash movie of how he came to his conclusions. It's very thorough.
Robi Sen ran his own tests against the SUN JVM. He contests the assertion that this is a Coldfusion issue and he's focused on the JVM. His results may be found
If you have read my previous posts on "Execution Plans" and Data Binding you know I am a big believer in using Cfqueryparam for performance as well as security. Today I picked up a tip on this topic from harelmalka.com (a blog I had never read before). I had never considered it before, but a query with no "WHERE" clause does not using binding because it lacks the opportunity. Therefore, a statement like:
Ben Forta posted this item on CF-Talk while discussing the nuances of moving to a multi-server instance. I thought it was a great illustration of some of the uses of CF Multi-server.
Ben Forta wrote:
It sounds like you are considering dedicated specialized instances, and I am a big fan of this. There is one customer I work with who has several sites in a single instance, like you do, but they have also created specific instances for specific needs. They have one that just does mailing, it receives requests from other instances, and process them. They have another which executes report requests on scheduled intervals. And another that builds Verity indexes when needed. These specialized instances require fewer threads, fewer data sources, no RDS and debugging (which you'd never want enabled on production servers anyway), and so on. That works very well. Of course, you may also want separate instances for specific apps, but that is a separate discussion.
I especially love the idea of a specialized instance for verity indexes. Re-indexing Verity collections is a huge resource hog, and larger collections can cause problems. I don't know why I never considered this approach before - very ingenious.
In regard to my previous post on Cfdocument and SSL I stand corrected. It is definitely possible to use a "file:" protocol identifier in the image path when using Cfdocument. My problem was with the syntax. As is often the case, a helpful reader put me on the right path. Thanks to Julian Halliwell for pointing out that my problem was syntax. I was trying 2 slashes as in:
Not only is this a rock solid fix for the SSL issue (see the previous post) but it has the potential to dramatically impact the speed of your cfdocument call, especially if you using large images. We have an application that embeds fairly large photographic images. I'm guessing this will greatly increase the speed of rendering. I'll post a follow up and let you know.