Note: This blog post is from 2019. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.Following on my recent announcement about speaking at CF Summit 2019, I am delighted to announce also that I've been selected to speak at CFCamp 2019, in Munich this October.
This will be my sixth year in a row presenting at this wonderful event, and my seventh year total. It will also be my 10th presentation there. (You can see all my past presentations, including when and where offered, at carehart.org/presentations.)
FWIW, half of those talks have been "sponsor" presentations on behalf of Intergral, the makers of FusionReactor, while the rest were not. And despite the title of my talk this year, "Comparing Monitoring Solutions for CF and Lucee", it is NOT an FR-sponsored talk. See the description below, for more.
Note: This blog post is from 2016. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.I'd like to take a diversion from my recent posts focused on CF2016 and talk about something that applies (and should interest) anyone using CF 10, 11, or 2016.
Have you heard of the new "metrics log" option that was enabled in CF10? If you have not, it's worth knowing about (there's precious little documentation, and I'll point to it, and give you still more info to help you use it). It's a useful, low-impact mechanism to get some high-level metrics logged by CF every 60 seconds (by default), and stored along with other CF logs.
If you did know about it, you've probably had some problems with it. Why does it show "nulls"? What do reported metrics really mean? Why do they not jive with what I'd expect to be the numbers reported?
In this post, and a Part 2 to come, I will introduce the metrics log, pointing out some key things you need to know to have it setup to work at all, and then I'll share my observations of things I've come to understand about the reported metrics.
Note: This blog post is from 2015. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.Just wanted to share word (sorry it took so long) that I'd been selected as a speaker at the upcoming dev.Objective() conference, in Minneapolis in Mid-May. Hope to see lots of my fellow CFers there, and of course new folks who were not CFers.
While the conference name has changed (from cf.Objective()), there are still plenty of CF-oriented topics, and of course as nearly everyone would point out, it's good for everyone to expand their reach and focus.
To that end, I'll be doing a topic a bit different than my normal focus of CF server troubleshooting. Instead, recognizing that there will be folks there who either use other servers, or develop web apps or mobile apps, I'll do a bit of a "soft" topic on how to troubleshoot performance problems more generically, in:
Hey, my web app's slow. Where's the problem?
Note: This blog post is from 2011. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.This is something that I find nearly no one has talked about, as a problem and solution. Did you know that by default, a single request doing a CFDOCUMENT may cause CF to execute several additional requests, each doing a CFHTTP to grab any images on the page? even if the images could be found locally on the server? This can be quite tragic.
The good news is that the problem can be solved using the simple LOCALURL attribute. The bad news is that you have to do it at all, and that if you don't do it, it can have such unfortunate and unexpected impact. (And just as bad, again, is that hardly anyone has talked about it.) This entry will elaborate on the issue (and a couple of other possible CFDocument performance issues, as a bonus.)
I've been meaning to write about the importance of this problem and solution (the LocalURL attribute) for a long time (it came out in CF8). Often when I'm helping people with CF troubleshooting problems, whether on mailing lists or in my consulting services, I've been able to show that long-running requests (or an unexpectedly excessive number of requests) were sometimes due to this very problem.
Basics of the LocalURL attribute
Note: This blog post is from 2010. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.How often have you seen (or seen others complain of getting) a CF page running longer than it's "supposed to" by a timeout you have set. Maybe you've set the CF Admin "request timeout" (first setting on first page of the Admin), or used the cfsetting requesttimeout tag or the timeout attribute on some specific tag if it's available, trying to get the request to "end" in 60 seconds, and yet you see a request running for 3 minutes, 3 hours, or 3 days! How can that happen?
Or same with if you've set the request to timeout using an alerting feature in a CF monitor like CF Enterprise server monitor, FusionReactor, or SeeFusion.
And perhaps you've seen this error from ColdFusion, in your logs or on-screen:
Do you know what this means? It's usually not what you think, and it may appear as I said 3 hours after a request was "supposed to timeout" in 60 seconds. I've even seen experienced CF developers who get thrown by this challenge. It's not new (and for those reading this even in the CF2016 era, it still happens). And it's not so much a "bug" (in either CF or the monitor tools) but just a situation that you need to understand, and there can be some ways to resolve things.
In this entry I'll try to help explain this surprisingly common problem and I hope to correct some equally common misconceptions. I'll even contend that the info in this error message is often useless and indeed misleading (and therefore the feature producing it ought not be relied upon completely, and should perhaps even be turned off for many). More important, again, there may be a way to "really" kill such a long-running request. Along the way, I'll share some things that I've not seen documented elsewhere.
I also share a solution that may work for query processing but it's NOT about a tag attribute but rather a CF Admin setting in the datasource "advanced settings" to set a "query timeout". This was added in CF 9, but many never noticed. If that's your problem and you want to skip to more on that here, feel free. but you may want to come back and read the rest as it is STILL not a perfect solution.
Strap on your seatbelts. We're going for a bit of a ride (if this situation was easy to understood in the length of a tweet, then perhaps everyone would already understand it and not find it challenging!) As always, I welcome feedback.
Note: This blog post is from 2010. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.This is a very interesting change in CF9 (and 9.0.1), which has slipped under the radar for the most part it seems.
Did you know there is now a setting in the DSN page of the CF Admin (for most of the Adobe-provided DB drivers) which allows you to set a maximum timeout for queries against that DSN?
It's a new feature enabled for the DataDirect drivers, as updated in CF 9. (You will not see it if you use an "other" datasource type, such as when using a downloaded JDBC driver that you implement on CF.)
The caveat? This timeout is ONLY settable there in the DSN definition, not in CFQUERY (or CFSTOREDPROC) itself, which is a shame. The existing TIMEOUT attribute for those (CF10 added it for CFSTOREDPROC) is not the same and generally does not work. Still, the value of this even at the DSN level is too important to ignore for some challenges. More on that (and some other thoughts) in a moment.
Note: This blog post is from 2010. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.I think most folks know that the underlying database drivers in CF are from DataDirect. Well, they've announced new "Type 5" drivers. While you would have to buy and install them separately from those built-into CF (for now, as Adobe has not yet certified CF for use with them), I think some people may want to give them serious consideration even before then.
Several Performance Advantages, and Failover As Well
Note: This blog post is from 2008. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.Hey folks, if you're having problems with your CF apps and you determine that (or wonder if) the cause may be due to problems in the database, check out Confio Ignite, a commercial tool that may be well worth the price for you.
Sure, there are many DB monitoring tools out there, but Ignite focuses on tracking, analyzing, reporting, and explaining wait events within the database--and you'd be amazed how often waits caused by your code, that of others, or from other operations in the DB are the explanation for poor performance. It can help target exactly what SQL statement or other operation is a cause of significant waits.
The tool presents the data aggregated over time, so you can view it per hour, day, week, etc. Great for both drilling down to find hot spots, and for viewing how coding/config improvements (resulting from your responding to the analyses) have led to performance improvements over time.
The tool runs with low overhead: it reads data that the DB provides, storing it in a database and providing a web-based interface to view that data. The process to read the data and create the repository (and present the web-based interface) can (and should) be done on a server separate from the server being monitored.
Here's a nice 2-minute demo. There's also a free trial, of course, and it's pretty quick and easy to install and benefit from.
As I noted in the title, it works with SQL Server, Oracle, DB2, or Sybase (sorry, not MySQL. Don't know why). And while it's a commercial product, it's not a ridiculously high price (as for some tools). I just learned of it in the past few weeks, and one customer of mine who tried it has been just thrilled with the results. I hope to write more about it later, but wanted to at least get this info out for folks to consider.
Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.You may have heard of the new Multiserver deployment option that was introduced in CFMX 6.1, also known as "multiple instances". It can bring tremendous performance and reliability improvements, allowing you to segregate apps on a single server either by function, or reliability, and so on. It can also help you manage memory more effectively.
Since many people may only be considering the feature now (either only now moving to 6.1 or 7, or 8), I want to share some resources if you're new to it. (The question came up on a list, and I offered the info there, so thought I'd pass it along here.)
First, there are a couple of articles from that time 6.1 frame:
"Introducing Multiple Server Instances in ColdFusion MX 6.1", by Tim Buntel
"Using Multiple Instances with ColdFusion MX Enterprise 6.1" video (sadly, seems no longer available)
Now, CF7 did introduce the new Instance Manager within the Admin, and that (and instances in general) is covered in the CF manual:
Configuring and Administering ColdFusion MX (Chapter 7, "Using Multiple Server Instances")
Finally, there is also a new Adobe article as of CF7:
(Update: There's also now a CF8 version of that: Multiple server instances using Adobe® ColdFusion® 8 Enterprise Edition. The technical content seems identical, but it appears to have had considerable editorial updating.)
There are certainly other articles folks have done in the CFDJ or at CommunityMX.com, but these should get you started.
Even though it's old news to some, it does seem that like many things, use of instances is something that may have been missed by folks. I've been contemplating a new user group presentation on the topic. Nothing new for CF8, but it seems people are considering things now that they may have ignored when 6, 6.1, or 7 came out (which is why I did my daylong class at CFUnited on what was new in 6 and 7 that folks may have missed).
One last point, if those don't make it: if you're running on Windows, don't try to create an instance with a JVM heap greater than about 1.3 GB. Though Windows should allow 2GB per app, this is just a number many found that beyond which CF won't start. Hope that all helps.