Request Tuning
Configure request queue, threading, and concurrent request handling
Overview
The Request Tuning page controls how ColdFusion processes concurrent requests and manages its thread pool. These settings directly impact server capacity, resource utilization, and overall performance under load. Proper configuration based on your hardware, application characteristics, and traffic patterns is essential for optimal server performance.
Concurrent Request Settings
Control how many requests ColdFusion can process simultaneously and how requests are queued.
Maximum Number of Running Requests
PurposeHard limit on concurrent requests that can execute simultaneously
Default50 (Enterprise), 10 (Standard), 5 (Developer)
CPU-Bound Apps2-4x number of CPU cores
I/O-Bound AppsCan be set much higher (100-300)
EnterpriseCan support 200-500+ concurrent requests with proper tuning
ImpactRequests beyond this limit are queued or rejected based on queue settings
Best Practice: Each request typically consumes 1-10 MB of memory. Start conservative and increase based on load testing results.
Maximum Number of Queued Requests
PurposeHow many requests can wait in queue before being rejected
Default200
Recommendation2-4x maximum running requests
ImpactRequests beyond running + queued limits receive "Request Rejected" error
User Experience: Long queues may result in poor user experience due to extended wait times. Monitor queue depth during peak load to identify bottlenecks.
Request Queue Timeout
PurposeMaximum time (seconds) a request can wait in queue
Default300 seconds (5 minutes)
Recommendation30-60 seconds for web applications
ImpactRequests waiting longer than timeout are rejected
Best Practice: Users typically abandon requests after 10-30 seconds. Set queue timeout lower than request timeout to fail fast and provide better user feedback.
Request Queue Timeout Page
PurposeCustom template to display when request queue timeout occurs
DefaultEmpty (shows generic error)
RecommendationCreate user-friendly error page
Example
/errors/queue-timeout.cfmContent Ideas: Explain that the server is experiencing high load, suggest trying again in a few moments, and provide alternative navigation options or contact information.
Request Throttling Settings
Protect your server from overload by automatically throttling request acceptance during high load.
Throttle Threshold
PurposeNumber of running requests that triggers throttling
Default4 (Enterprise), varies by edition
RecommendationSet to 70-80% of maximum running requests
ImpactWhen exceeded, ColdFusion increases delays between accepting new requests
Best Practice: Enable throttling to protect server stability and prevent overload during traffic spikes.
Throttle Memory
PurposeMemory threshold (percentage) that triggers request throttling
Default80%
Recommendation70-80% for production servers
ImpactSlows request acceptance when memory usage is high to prevent OutOfMemoryError
Monitoring: Watch for frequent throttling as it indicates undersized heap. Consider increasing JVM heap size or optimizing memory usage.
Request-Specific Limits
Set separate concurrent request limits for different types of operations.
Flash Remoting Requests
- Default
- 5
- Recommendation
- 0 (legacy, use REST APIs instead)
Flash Remoting is deprecated and rarely used in modern applications. Set to 0 if not using Flash.
Web Service Requests
- Default
- 10
- Recommendation
- Set based on SOAP usage patterns
SOAP web service calls are often slower than regular requests. Consider REST APIs for better performance.
CFC Function Requests
- Default
- 10
- Recommendation
- 25-100 for heavy API usage
Remote CFC method invocations for AJAX requests and API endpoints. Lower values help prevent API abuse.
Report Requests
- Default
- 5
- Recommendation
- Keep low (3-5), use async generation
CFReport is resource-intensive. Use cfthread or scheduled tasks for large reports during off-peak hours.
Chart Requests
- Default
- 10
- Recommendation
- 5-15 depending on chart complexity
Chart generation uses significant CPU and memory. Consider JavaScript charting libraries (Chart.js, Highcharts).
PDF Requests
- Default
- 10
- Recommendation
- 10-20 for typical usage
PDF operations can be CPU and memory intensive. Use cfthread for large PDF generation to avoid blocking.
Thread Pool Settings
Configure thread pool limits for asynchronous processing with cfthread.
Maximum Number of CFThread Threads
PurposeConcurrent limit for cfthread operations
Default10
Recommendation25-100 for applications using async processing
ImpactAdditional threads beyond limit are queued
Use CaseBackground processing, parallel operations, async tasks
Memory Consideration: Each thread consumes memory (typically 1-5 MB). Balance concurrency needs with available memory.
Request Timeout in CFThread
PurposeDefault timeout for cfthread operations
DefaultInherits from request timeout
RecommendationSet explicitly for long-running async tasks
Best Practice: Override in code using cfthread timeout attribute for better control over individual thread timeouts.
Calculating Optimal Settings
Use these formulas as starting points based on your application characteristics.
CPU-Bound Applications
- Characteristics
- Complex calculations, heavy business logic, minimal database calls
- Formula
- Max Requests = CPU Cores × 2 to 4
- Example
- 8-core server = 16-32 concurrent requests
CPU becomes bottleneck. Too many threads cause context switching and degrade performance.
I/O-Bound Applications
- Characteristics
- Database queries, web service calls, file operations
- Formula
- Max Requests = CPU Cores × 10 to 50
- Example
- 8-core server = 80-400 concurrent requests
Threads spend time waiting for I/O, allowing server to handle more concurrent work efficiently.
Hybrid Applications
- Characteristics
- Most common - mix of CPU and I/O operations
- Starting Point
- Max Requests = CPU Cores × 5 to 10
- Example
- 8-core server = 40-80 concurrent requests
Adjust based on load testing and monitoring. This is the most common application profile.
Memory Constraints
- Formula
- Max = (Heap - Overhead) / Avg Request Memory
- Example
- 4 GB heap, 500 MB overhead, 5 MB/request = 700 theoretical max
- Reality
- Set 20-40% of theoretical max for stability
Always leave headroom for GC and memory spikes. Monitor heap usage under peak load.
Best Practices
Production Environment
- Start with conservative limits based on CPU cores
- Perform load testing to determine optimal concurrent request limit
- Enable request throttling to protect against overload
- Set request queue timeout lower than request timeout
- Monitor queue depth, request wait times, and rejection rates
- Keep Flash Remoting and Report limits low (or disabled if unused)
- Allocate sufficient memory per thread (monitor heap usage)
- Create custom timeout pages for better user experience
Development Environment
- Higher request limits for testing concurrent scenarios
- Longer timeouts to accommodate debugging
- Match production settings when performing load testing
- Test timeout and rejection behavior before production deployment
Security Considerations
- Lower concurrent limits help prevent resource exhaustion attacks
- Set conservative CFC function limits to prevent API abuse
- Monitor for unusual request patterns indicating attacks
- Enable request throttling to mitigate denial-of-service attempts
- Log rejected requests for security analysis
Performance Tuning
- Use load testing tools (JMeter, LoadRunner) to determine optimal settings
- Monitor CPU utilization - should be 70-80% under peak load
- Track request queue depth - should rarely exceed 10-20
- Measure response times at various concurrent request levels
- Identify optimal point before performance degrades
- Leave 20-30% headroom for traffic spikes
- Retest after application changes or infrastructure upgrades
Common Issues and Solutions
Request Rejected Errors
Symptom: Users receiving "Request Rejected" or "Request Queue Full" errors
Solutions:
- Cause: Concurrent requests exceed running + queued limits
- Short-term: Increase concurrent request limit or queue size
- Long-term: Optimize slow requests, add more servers, implement caching
- Analysis: Identify slow requests causing queue backup
High CPU with Low Throughput
Symptom: CPU at 90-100% but request throughput is low
Solutions:
- Cause: Too many concurrent requests causing context switching
- Solution: Reduce maximum concurrent requests
- Target: CPU should be 70-80% under peak load for optimal performance
Request Queue Timeouts
Symptom: Requests timing out while waiting in queue
Solutions:
- Cause: Request processing too slow or concurrent limit too low
- Solution: Optimize slow requests or increase concurrent limit
- Analysis: Use FusionReactor or CF Server Monitor to identify bottlenecks
Memory Exhaustion
Symptom: OutOfMemoryError or GC overhead limit exceeded
Solutions:
- Cause: Too many concurrent requests for available heap
- Solution: Reduce concurrent limits or increase heap size
- Formula: Ensure (Max Requests × Avg Request Memory) less than 60% of heap
Slow Response Times Under Load
Symptom: Response times increase significantly during peak traffic
Solutions:
- Cause: Request queue building up, insufficient capacity
- Solution: Optimize application code, increase concurrent limits, add servers
- Monitoring: Track response time percentiles (p50, p95, p99)
Load Testing Strategy
Testing Methodology
- Baseline Test: Measure performance with conservative settings
- Incremental Increase: Gradually increase concurrent requests
- Monitor Metrics: Track CPU, memory, response times, queue depth
- Identify Peak: Find optimal concurrent requests before degradation
- Add Buffer: Set production limit 20-30% below peak
- Validate: Confirm stability over extended duration
Key Metrics to Monitor
- Response Time: p50, p95, p99 percentiles
- Throughput: Requests per second
- CPU Utilization: Target 70-80% under load
- Memory Usage: Heap utilization and GC frequency
- Queue Depth: Average and peak queue size
- Rejection Rate: Percentage of rejected requests
- Error Rate: Timeouts and application errors
Load Testing Tools
- Apache JMeter: Free, powerful, widely used
- LoadRunner: Enterprise solution with advanced features
- Gatling: Code-based load testing
- Artillery: Modern, YAML-based configuration
- CloudFlare Workers: Distributed load testing
Monitoring and Alerting
Critical Alerts
- Request queue depth exceeds 50% of maximum
- Request rejection rate above 1%
- Average request wait time exceeds 1 second
- CPU sustained above 85% for 5+ minutes
- Memory throttling activated
Monitoring Tools
- FusionReactor: Real-time request monitoring, thread analysis
- CF Server Monitor: Built-in Enterprise edition monitoring
- New Relic / AppDynamics: APM solutions with alerting
- Prometheus + Grafana: Custom metrics and dashboards
- CloudWatch / Azure Monitor: Cloud-native monitoring