IIS is the web server foundation for SyteLine's browser-based user interface, REST APIs, and IDO web services. Default IIS settings are not optimized for SyteLine's demanding request patterns, which include long-running IDO calls, large dataset responses, and concurrent form loads. Targeted IIS tuning delivers measurable improvements in SyteLine responsiveness.
Application Pool Configuration
SyteLine application pools require specific settings that differ from general web hosting defaults. The recycling schedule, worker process limits, and idle timeout all impact SyteLine session stability and performance. Misconfigured application pools cause mid-session disconnects that frustrate shop floor users.
Dedicated application pool per SyteLine site with .NET CLR version matching SyteLine requirements
Disable idle timeout or set to 0 to prevent SyteLine worker process shutdown during breaks
Regular time recycling scheduled during non-production hours (e.g., 2:00 AM daily)
Maximum worker processes set to 1 unless SyteLine is explicitly configured for web garden mode
Private memory limit set to 0 (unlimited) with external monitoring for memory leak detection
Request Processing and Timeout Settings
SyteLine IDO operations can execute long-running queries that exceed default IIS timeout values. MRP regeneration, large BOM explosions, and complex report generation all require extended timeout configurations. Without these adjustments, users see timeout errors during legitimate long-running operations.
Connection timeout increased to 300 seconds for SyteLine sites handling MRP and planning operations
Request filtering maxAllowedContentLength set to accommodate SyteLine file upload requirements
Output caching configured for static SyteLine resources: CSS, JavaScript, images, and font files
Dynamic compression enabled for SyteLine IDO JSON responses to reduce bandwidth consumption
Failed Request Tracing enabled for SyteLine URLs to diagnose intermittent 500 errors
Performance Monitoring and Diagnostics
IIS performance counters specific to SyteLine workloads provide the data needed for ongoing optimization. Monitor request execution time, queue length, and memory utilization to identify degradation before users report slowness. These metrics also validate the impact of configuration changes.
IIS request execution time tracking for SyteLine IDO endpoints vs static content
Application pool worker process memory and CPU monitoring with alerting thresholds
HTTP.sys kernel queue length monitoring to detect SyteLine request queuing under load
W3C extended logging with time-taken field for SyteLine request performance analysis
Windows Performance Monitor data collector sets for SyteLine-specific IIS counters
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.
Speed up your SyteLine web interface with expert IIS optimization -- schedule a performance review.
1. How large are your biggest transaction tables (matltran_mst, ledger_mst, jobtran_mst), and do you purge or archive them?
Check row counts with sp_spaceused or sys.dm_db_partition_stats. Fix: agree a retention policy with finance and audit, then run the SyteLine purge utilities for history you no longer need online, testing on a copy first.
2. How often are index maintenance and statistics updates run on the application database?
Fix: schedule index reorganise or rebuild based on fragmentation from sys.dm_db_index_physical_stats, plus UPDATE STATISTICS on the large _mst tables, in a window outside TaskMan peaks.
3. How many custom (non-Infor) triggers exist on _mst tables?
List them from sys.triggers joined to sys.tables and compare with a clean install. Fix: move logic out of triggers into IDO events or scheduled processes where possible, and keep any remaining trigger set-based, never row by row with cursors.
4. How many EXTGEN_ stored procedure overrides are in place?
An EXTGEN_ procedure replaces the standard procedure of the same base name, so every override is code that runs instead of Infor's on every call and is not upgraded with it. Fix: review the EXTGEN Listing, retire overrides that newer releases made unnecessary, and profile the ones on hot paths (order entry, posting, MRP/APS).
5. Do IDO extension classes or scripts call LoadCollection with RecordCap 0 (no cap) or without an explicit property list?
In Mongoose, RecordCap 0 retrieves all records and -1 uses the system default cap. Fix: always pass a PropertyList with only the properties you need, a tight Filter, a real RecordCap, and a ReadMode suited to the read; in REST v2 calls use props and readonly=true for loads that will not be updated.
6. Do form personalisations add unbound properties filled by a per-row method call (post-query commands)?
A PostQueryCmd (pqc in REST) runs a method once for every row returned, so a grid of 500 rows makes 500 extra calls. Fix: replace per-row methods with a derived property or a joined subcollection computed in one set-based query, or cap the grid.
7. How do integrations (web store, MES, EDI, BI) read SyteLine data?
Fix: replace one-minute polling of full collections with change-based filters (for example RecordDate greater than the last run), longer intervals, or event-driven outbound messages, and give each integration its own user so its load is visible.
8. What is your TaskMan background task backlog at peak?
Look at queued versus running tasks and durations in Background Task History (BGTaskHistory). Fix: stagger scheduled reports and utilities, move heavy jobs out of business hours, and find the longest-running tasks before adding more TaskMan capacity.
9. Is SQL Server max server memory set deliberately on the database server?
Check with sp_configure 'max server memory (MB)' (enable 'show advanced options' first) or in the Memory page of server properties in SSMS. Fix: set it to leave headroom for the OS and anything else on the box (often the case when the utility or web server shares the machine), and confirm the buffer pool is not being trimmed.
10. How is tempdb configured?
Fix: use multiple equally sized tempdb data files (Microsoft's guidance: one per logical processor up to eight, then add files in multiples of four only if allocation contention continues), pre-size them to avoid autogrowth during month-end, and place them on fast storage.
11. How much blocking do you see at month-end close?
Capture it with sys.dm_exec_requests (blocking_session_id) or the blocking script generator linked below. Fix: identify the head blocker (often a long posting, report or custom trigger), shorten its transaction, and add the supporting index.
12. Where do heavy reports and BI queries run during business hours?
Fix: move heavy reporting to a reporting copy (for example an Always On readable secondary, log shipping or a nightly restore) and schedule the rest off-peak through TaskMan.