# Infor LN Performance Tuning Checklist > Source: https://netray.co/tools/infor-ln-performance-tuning-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A 30-point practitioner checklist for diagnosing and fixing Infor LN performance problems across database, application tier, batch jobs, custom code, and monitoring. ## Category infor-ln ## Tool **Kind:** checklist **Groups:** #### Database and Storage **Items:** **Text:** Index maintenance (rebuild/reorganize) runs on a schedule, and fragmentation on the top 20 LN tables is below 30% **Critical:** true **Text:** Database statistics are updated at least weekly on high-churn tables so the optimizer chooses correct plans **Critical:** true Data files, log files, and tempdb (or redo/undo) sit on separate storage paths with verified IOPS headroom The top 20 slowest queries have been identified from database monitoring within the last quarter Table growth is managed: closed transactional data older than the retention policy is archived out of hot tables Database server memory allocation follows vendor guidance and the buffer cache hit ratio is consistently above 95% #### Application Server and bshell Configuration **Items:** **Text:** bshell memory settings are tuned per vendor guidance rather than left at installation defaults **Critical:** true The number of concurrent user sessions per application server is within sized limits, with load balanced across servers Timeouts and keepalive settings between web UI, application tier, and database are aligned and documented Application server OS patches and LN solution updates relevant to performance are reviewed and applied on a cadence Print and report processing is offloaded so heavy report generation cannot starve interactive sessions **Text:** Network latency between application tier and database tier is measured and below 1ms for on-prem deployments **Critical:** true #### Batch Jobs and Background Processing **Items:** **Text:** MRP / planning runs are scheduled outside interactive peak hours and their runtimes are trended over time **Critical:** true Job daemon queues are configured so long-running batch jobs cannot block short operational jobs Overlapping heavy jobs (planning, invoicing, integration bursts) are deconflicted in a documented batch calendar Failed or hung jobs generate alerts rather than being discovered by users the next morning Batch job runtimes that grow more than 20% quarter over quarter trigger investigation before they hit windows Session defaults for heavy processes (ranges, warehouses, date windows) prevent accidental full-scope runs #### Custom Code and Query Hygiene **Items:** **Text:** Custom sessions and scripts touching high-volume tables have been profiled for full-table scans **Critical:** true **Text:** Custom reports run against appropriate indexes or a reporting replica, not unindexed production queries at peak **Critical:** true Loops in custom 4GL code avoid record-by-record database round trips where set-based operations exist Direct database access from external tools (BI, spreadsheets, integrations) is inventoried and throttled Customizations added in the last year passed a performance review before production release Unused customizations identified by usage analysis have been retired rather than left executing triggers and hooks #### Monitoring and Capacity Planning **Items:** **Text:** End-user response times for 5-10 key sessions are measured continuously, not just server-side metrics **Critical:** true Baseline performance metrics exist, so 'the system is slow' can be compared against known-good numbers CPU, memory, and I/O utilization on database and application tiers are trended with alerts before saturation Capacity projections account for planned growth (users, sites, transaction volume) at least 12 months ahead A documented escalation runbook exists for performance incidents, including which vendor logs to capture Performance is reviewed as a standing agenda item at least quarterly, not only after user complaints **Scoring Note:** Score yourself honestly: items you cannot verify count as unchecked. Critical items (flagged) are the ones that most often explain severe LN slowdowns - if any critical item is unchecked, start there regardless of your overall score. Above 80% checked, remaining gains usually come from capacity planning; below 50%, systematic tuning typically recovers 30-50% of response time. ## Content **Intro:** This free 30-point checklist gives Infor LN administrators, DBAs, and IT managers a systematic way to diagnose and fix LN performance problems. It covers the five layers where LN slowdowns actually originate: database and storage, application server and bshell configuration, batch processing, custom code, and monitoring. Each item is a concrete, verifiable practice, with the highest-impact items flagged as critical. Work through it before your next performance escalation - most severe LN slowdowns trace to a handful of these items, and most of them are fixable without hardware spend. **Sections:** #### How to use this checklist **Body:** Treat it as an audit, not a survey: check an item only if you can point to evidence - a maintenance job schedule, a monitoring dashboard, a documented setting. Run through all five groups first to get the full picture, because LN performance problems are frequently cross-layer: a slow session blamed on the database often turns out to be a custom report doing full-table scans during an overlapping MRP run. Then fix in this order: all unchecked critical items first, then the cheapest remaining items in your worst-scoring group. Re-measure your key session response times after each change so improvements are attributed, not assumed. #### Where LN performance problems actually come from **Body:** Across LN environments we are asked to rescue, the distribution of root causes is remarkably consistent, and it is why the critical flags sit where they do: **Bullets:** - Database neglect - stale statistics and fragmented indexes - explains the largest share of severe interactive slowdowns - Custom code doing record-by-record processing or unindexed queries against high-volume tables is the next largest cause - Batch collisions, especially MRP or invoicing overlapping peak interactive hours, produce the 'system freezes every Tuesday' pattern - Genuine hardware undersizing is the least common cause, yet it is where organizations spend first #### Interpreting your score **Body:** Below 50% checked, your environment has systematic tuning debt, and the good news is that returns are steep: environments in this range typically recover 30-50% of interactive response time from the critical items alone, without new hardware. Between 50% and 80%, you have the basics but likely lack the measurement discipline to catch regressions - prioritize the monitoring group, because you cannot hold gains you cannot see. Above 80%, remaining problems are usually capacity or architecture questions: consolidation pressure, data volume growth, or an aging platform version. At that point the checklist's value shifts from fixing to defending - re-run it quarterly and after every major change. #### How Netray helps when the checklist is not enough **Body:** Netray runs structured LN performance rescues: we baseline your key sessions, instrument all five layers, and work the evidence - query plans, bshell traces, batch calendars, and custom-code profiling - to the actual root cause rather than the loudest theory. Our AI-assisted code analysis is particularly effective on the custom-code layer, scanning your entire 4GL portfolio for full-scan patterns and record-by-record loops in hours instead of weeks. Typical engagements deliver measured response-time improvements inside four to six weeks, with a tuning runbook your team keeps. If your checklist score is low and users are escalating, that is exactly the situation we are built for. **Cta:** Work through the checklist, then bring your unchecked criticals to a Netray LN performance specialist for a targeted rescue plan. **Faq:** #### Our LN system is slow but the servers show low CPU - how is that possible? **Answer:** Low CPU with poor response time is the classic signature of waiting rather than working: sessions blocked on database locks, I/O queues, fragmented indexes forcing excessive reads, or a batch job holding resources interactive sessions need. It can also indicate network latency between tiers or bshell settings throttling throughput. This is precisely why the checklist emphasizes end-user response measurement and cross-layer evidence - server utilization graphs alone routinely point teams at the wrong layer. #### Should we just add hardware to fix LN performance? **Answer:** Usually not first. Hardware is the least common root cause of severe LN slowdowns and the most expensive guess - stale statistics, fragmented indexes, unprofiled custom code, and batch collisions do not get better with more cores; they get better hidden, temporarily. The disciplined sequence is: fix the critical checklist items, measure, and only then size hardware against the remaining, now-understood load. Environments that upgrade hardware before tuning typically buy 12-18 months before the same symptoms return. #### How often should MRP and other heavy batch jobs run, and when? **Answer:** Planning runs belong outside interactive peak hours - overnight for single-region businesses, in a carefully placed window for global ones - and their runtimes should be trended so growth is caught before the window overflows. Frequency is a business decision: many discrete manufacturers run full regenerative MRP nightly with net-change during the day, but the performance principle is deconfliction. A documented batch calendar that prevents planning, invoicing, and integration bursts from overlapping is worth more than any single tuning parameter. ## Search terms infor ln performance tuning, infor ln slow performance, ln database optimization, infor ln batch job tuning, ln bshell performance, erp performance checklist, infor ln session slow --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json