Some folks, using it with CF2021 or 2023 found CF was somehow heavily impacting their Redis instance. The good news is that I've found an easy fix/workaround (until Adobe fixes it formally).
For more (including why you may or may NOT be impacted by the issue), read on.
My talk will be...
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:
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.
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.
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.
Managed Hosting Services provided by
