The last lesson was about fixing a known slowdown. This one closes out Module 16 with the step that comes before that: knowing something's wrong at all, ideally before a user has to tell you.
Learning Objectives
After completing this lesson, you'll be able to:
- Know what to watch at each layer: server, JVM, ColdFusion requests, database, and external APIs.
- Recognize when rising garbage collection activity means something other than "increase the heap."
- Use Adobe's Performance Monitoring Toolset (PMT) for topology discovery and proactive alerting.
- Set alert thresholds that catch a problem before users notice it.
How Monitoring Fits Together
Collect Metrics
CPU, memory, requests, queries
Analyze Trends
rising error rate? growing heap?
Alert on Thresholds
before users notice
Investigate and Fix
at whichever layer actually owns it
What to Watch, Layer by Layer
| Layer | Watch For |
|---|---|
| Server | CPU, RAM, disk space, network |
| JVM | Heap usage, garbage collection frequency/pauses, thread count |
| ColdFusion | Request execution time, active requests, error rate |
| Database | Query execution time, connection pool usage, locks |
| External APIs | Response latency, timeout frequency, failed requests |
A ColdFusion server can look perfectly healthy while the database or a third-party API it depends on is the actual problem, which is why all five layers matter, not just the one labeled "ColdFusion."
A Real Detail: Rising GC Activity Isn't Automatically a "Need More Heap" Signal
If garbage collection cycles are getting more frequent or pauses are getting longer, the instinct is to just raise the heap size. The previous lesson's JVM tuning guidance applies here directly: investigate what's actually consuming memory (a leak, an unexpectedly large session-scoped object) and apply the matching fix, like -XX:+UseG1GC for a heap of 4GB or more, rather than treating a bigger heap as the default answer.
Watching the Database Layer
A single query that takes 5 seconds is a minor annoyance at low traffic and a serious problem the moment hundreds of users hit it simultaneously, since each one holds a connection open for that whole 5 seconds.
<cfquery name="getProducts" datasource="myDSN">
SELECT id, name, price
FROM products
WHERE status = <cfqueryparam value="active" cfsqltype="cf_sql_varchar">
</cfquery>Watch query execution time and connection pool usage together, a slow query and a saturated connection pool are often the same underlying problem showing up two different ways.
Watching External API Calls
An outbound cfhttp call (Module 14) adds a third-party server's latency directly onto your own page's response time. A timeout attribute limits how long a single slow call can hold up the request, but it still needs to be watched, since a struggling third-party API degrades your own application's response times even though your own code is fine.
<cfhttp url="https://api.example.com/users" method="GET" timeout="10"> </cfhttp>
Adobe's Performance Monitoring Toolset (PMT)
PMT is Adobe's current monitoring tool, supported on both the Standard and Enterprise editions. On first launch, it automatically discovers ColdFusion nodes on the network using multicast, and builds a topology view covering external services, databases, applications, instances, clusters, and sites, so you can see the full picture rather than just one server's own metrics. It identifies and sends alerts before problems reach critical processes.
Common Beginner Mistakes
Only monitoring the ColdFusion server itself
A slow database or a struggling third-party API makes the application slow regardless of how healthy ColdFusion's own metrics look. Watch the database and external API layers too, not just ColdFusion's request metrics.
Increasing heap size as the automatic response to rising GC activity
Investigate what's actually consuming the memory first, a leak or an oversized session object needs a different fix than a bigger heap.
Waiting for users to report a problem instead of alerting on thresholds
Alerting on CPU, memory, disk, error rate, and response time thresholds catches a developing problem while it's still minor, rather than finding out once it's already affecting users.
Ignoring repeated errors in the logs because nobody's complained yet
A repeated error in the logs that hasn't been reported yet is often a problem that just hasn't hit enough users to generate a complaint, not a problem that isn't real.
Best Practices
- Monitor all five layers (server, JVM, ColdFusion, database, external APIs), not just the one that's easiest to check.
- Set alert thresholds (CPU, memory, disk, error rate, response time) so a developing problem surfaces before users report it.
- Treat rising GC activity as a signal to investigate memory usage, not an automatic cue to raise the heap.
- Use PMT's topology view to see the full stack when diagnosing a problem, rather than assuming it's isolated to one server.
Interview Questions
Why would a ColdFusion application be slow even if ColdFusion's own server metrics look completely healthy?
The bottleneck can be at a different layer entirely, a slow database query, a saturated connection pool, or a struggling third-party API being called over cfhttp. Monitoring needs to cover all of those layers, not just ColdFusion's own request metrics.
What's the right first response to rising garbage collection activity, increasing the heap size or something else?
Investigate what's actually consuming memory first, like a leak or an oversized session-scoped object. The matching fix (a different GC algorithm, fixing the leak) is often more effective than just raising the heap.
What does Adobe's Performance Monitoring Toolset's auto-discovery feature actually do?
On first launch, it uses multicast to automatically discover ColdFusion nodes on the network, then builds a topology view covering external services, databases, applications, instances, clusters, and sites.
Summary
In this lesson, you covered what to watch at each layer of a ColdFusion application, saw why rising GC activity isn't automatically a "need more heap" signal, watched the database and external API layers specifically, and used Adobe's Performance Monitoring Toolset for topology discovery and proactive alerting. That closes out Module 16: Performance.
What's Next?
Module 17 moves into Frameworks & Deployment, starting with an introduction to MVC.