Plan full-scan time, monitor realtime coverage, and control CPU and memory on shared hosting or a dedicated IIS server without mistaking a slow scan for immediate protection.
Not rated yet
DNN Defender runs several jobs on different clocks. The WAF evaluates a request as it arrives;
Realtime Monitor reacts to an eligible file change; a scheduled full scan examines files already
present; FIM compares protected files with an approved baseline. An 8-files-per-second full-scan
limit does not throttle the WAF to eight requests per second. It does affect how long an initial
or scheduled inventory can take.
Estimate the initial scan
The current scheduler caps MaxScanSpeed at 8 eligible files per second and waits at least 100 ms
after each file. At the theoretical ceiling, 100,000 eligible files take at least 3.5 hours. At
1–3 files per second, the same set takes roughly 9–28 hours before archive expansion, large files,
I/O contention, retries, or hosting limits. The count is of eligible files after scope filtering,
not every image, JavaScript file, or cache entry under the DNN root. A scan that has not completed
is not evidence that all older files have been examined.
For first deployment, review bin, root server-executable files, web.config, handlers, unexpected
ASPX/ASHX/ASMX under Portals, and recent changes while the background inventory runs. Record the
scan start, completed count, last progress time, errors, and final completion. Treat a stopped
scanner or an unavailable engine as an operational failure that needs action.
Realtime window and resource controls
Realtime Monitor queues relevant new or changed server-side artifacts for analysis. It narrows
the gap between full scans, but a filesystem watcher is asynchronous: an attacker may invoke an
uploaded shell before a later file verdict or quarantine action. Keep request-time upload and
execution-path controls in Prevention/Strict when the site's normal workflows have been tested.
Prioritize investigation of an executable in a writable content folder, regardless of whether a
later full scan reaches it.
The scanner enumerates eligible paths lazily, reuses the model during a run, applies file and
archive limits, excludes ordinary .js, .map, media and cache assets from the web-shell pipeline,
and releases scan resources at the end. Memory depends on the IIS application pool, model, file
size, archives, installed modules, and traffic. There is no single honest RAM number for every
site; monitor private bytes, CPU, disk response and page latency during a real run.
- Shared hosting: begin at 1–3 eligible files per second during a quiet period, keep Realtime
Monitor enabled, and investigate host timeouts or repeated scheduler aborts.
- Dedicated IIS: increase towards the enforced ceiling only after observing CPU, private bytes,
request latency and disk I/O under normal load.
- Both: retain WAF/Realtime/FIM health and freshness indicators so an unfinished scan, missed
change event or stale baseline cannot be mistaken for a healthy result.