Enabling IDO Request Tracing and Performance Logging
SyteLine's IDO runtime includes built-in request tracing that logs every IDO method call with execution time, row count, and SQL generation details. config file on the application server, setting the IDOTracing element to true and specifying a log output directory. Configure the trace level to Performance to capture timing data without the verbose payload logging that can generate 10+ GB of logs per day.
Use the IDO Performance Analyzer tool in System Administration to aggregate trace data and identify the slowest IDO operations.
- Edit SLRuntime.config to set IDOTracing=true with TraceLevel=Performance and specify a log directory on a fast SSD volume
- Configure trace file rotation with MaxFileSize=100MB and MaxFiles=20 to maintain 2 GB of rolling trace history
- Use the IDO Performance Analyzer form to identify IDO methods exceeding 5-second execution times for optimization targeting
- Set up automated trace analysis that flags IDO calls exceeding baseline thresholds by more than 200% indicating regression
SQL Server Query Performance Diagnostics
The SyteLine database layer is typically the primary bottleneck in performance-constrained environments. Enable SQL Server Query Store on the SyteLine database to capture query execution plans, runtime statistics, and plan regression data. Configure the Query Store retention to 30 days and data flush interval to 15 minutes.
Use the Top Resource Consuming Queries report in SSMS to identify queries consuming the most CPU, I/O, or elapsed time. Cross-reference slow queries with IDO trace logs to map database bottlenecks to specific SyteLine forms and operations.
- Enable Query Store on the SyteLine database with MAX_STORAGE_SIZE_MB=2048 and DATA_FLUSH_INTERVAL_SECONDS=900
- Review Top Resource Consuming Queries weekly and focus on queries with average execution time exceeding 1 second
- Create missing indexes identified by SQL Server's DMV sys.dm_db_missing_index_suggestions with an improvement measure above 50000
- Monitor wait statistics using sys.dm_os_wait_stats to identify whether bottlenecks are CPU-bound, I/O-bound, or lock-bound
Application Server and User Experience Monitoring
NET request queue length, current connections, and request execution time. Set up custom performance counters for the SyteLine application pool to monitor memory consumption, CPU utilization, and thread pool exhaustion. For end-user experience monitoring, deploy a synthetic monitoring solution that simulates user logins and common form navigation sequences every 5 minutes, alerting when response times exceed acceptable thresholds.
- Add Performance Monitor counters for ASP.NET Applications Request Execution Time and Requests Queued targeting the SyteLine app pool
- Set alert rules to trigger when request queue length exceeds 10 for more than 2 minutes indicating application server saturation
- Configure SyteLine Health Dashboard form to display real-time session counts, active IDO requests, and background task status
- Deploy synthetic monitoring scripts that log into SyteLine and navigate to key forms every 5 minutes to detect slowdowns proactively
Try it here, free
SyteLine IDO and SQL Performance Assessment
Score the performance risk of a SyteLine 9 or 10 on-prem install across data growth, IDO and extension code, background tasks and SQL Server configuration, with the specific fix for each weak answer.
Frequently asked questions
What is the acceptable response time for SyteLine forms?
Industry best practice targets sub-3-second form load times for interactive forms and sub-10-second execution for complex operations like MRP inquiry or report generation. Form loads exceeding 5 seconds significantly impact user productivity, studies show a 25% drop in data entry throughput when average response times exceed 4 seconds. Monitor the 95th percentile response time, not just averages, to capture the experience of your slowest-performing users.
How do I identify the root cause of slow SyteLine performance?
Follow a systematic top-down approach. First, check application server CPU and memory in Performance Monitor, if CPU exceeds 80%, the bottleneck is compute. If CPU is low but forms are slow, examine SQL Server wait statistics using sys.dm_os_wait_stats. PAGEIOLATCH waits indicate storage I/O issues, LCK waits indicate blocking, and SOS_SCHEDULER_YIELD indicates CPU pressure. Cross-reference with IDO trace logs to identify the specific forms and operations affected.
Should I enable IDO tracing in production?
Yes, but at the Performance trace level only. Performance-level tracing adds approximately 2-5% overhead to IDO processing, negligible for most environments. Avoid enabling Debug or Verbose trace levels in production as they generate 10-50 GB of log data per day and add 15-25% processing overhead. Configure log rotation to prevent disk space exhaustion and archive trace files weekly for trend analysis.
Want comprehensive SyteLine performance visibility? Netray's monitoring agents can configure dashboards and alerting for your entire SyteLine infrastructure, contact us.