Performance

Diagnose slow NetStacks Terminal performance: scrollback memory, many concurrent sessions, AI streaming load, SFTP transfers, discovery concurrency, and the local SQLite database.

Overview

NetStacks Terminal is a desktop application (macOS, Windows, Linux) built on Tauri. It runs as a single window with multiple tabs, alongside a Local Agent sidecar process that handles SSH, Telnet, SFTP, SNMP, discovery, the AI assistant, and an encrypted credential vault. All state is stored locally in a single SQLite database on your own machine. There is no server, no PostgreSQL, no reverse proxy, and no phone-home telemetry.

Because everything runs on one workstation, performance issues are almost always one of a few things: a huge terminal scrollback buffer, a large number of simultaneously open sessions, the AI assistant streaming and analysing output, a big SFTP transfer, or a wide network discovery. This page walks through each, with the verified defaults the product ships with so you know what you are actually tuning.

Free, single-user product

The open, free NetStacks Terminal is single-user and self-contained. The separate commercial Controller (multi-user vault, RBAC, audit log, plugins) is a different product with its own scaling considerations and is not covered here.

Where Performance Comes From

Knowing which component does the work helps you point diagnosis at the right place.

Desktop UI (WebView) — renders tabs, the terminal grid, topology, and dialogs. Heavy DOM (very large tables) or a massive scrollback buffer shows up here as a laggy or unresponsive window.
Local Agent (Rust sidecar) — owns every network connection, the AI pipeline, discovery, and database access. CPU spikes during discovery, AI streaming, or many active sessions live here.
SQLite database — stores profiles, sessions, snippets, vault entries, discovery results, and enrichment data in a single netstacks.db file in your OS app-data directory. It runs in WAL mode and uses a small internal pool, so it is rarely the bottleneck for a single user.
Remote devices and the network — the most common real cause of "slowness." Round-trip latency to the device, slow device CPUs, and rate-limited VTY lines dominate the experience of typing and of bulk work.

Check the network first

Before tuning anything local, confirm the round-trip time to the target device. A device 200 ms away will feel laggy no matter how the app is configured.

Terminal & Scrollback

Each terminal keeps a scrollback buffer in memory. The default is 10,000 lines per session, set per credential profile. Large buffers consume memory and can slow searching, highlighting, and copy operations — especially when many tabs are open at once.

Adjust scrollback per profile

Open a credential profile in the profile editor and change the Scrollback Lines field. Lower it to a few thousand for chatty sessions (for example log tailing) where you do not need deep history; raise it only when you genuinely scroll back far.

Credential profile defaultstext

Profile defaults (verified)
  Scrollback Lines ........ 10000   (lines kept in memory per session)
  Keepalive Interval ...... 30      (seconds)
  Connection Timeout ...... 30      (seconds)
  Reconnect Delay ......... 5       (seconds, when auto-reconnect is on)

If the window feels heavy

Clear scrollback on a noisy tab (the terminal command menu has a clear / reset action) instead of letting it grow to the cap.
Lower the scrollback line count in the profile you use for high-volume output.
Disable real-time output highlighting on extremely fast streams if your machine is older; highlighting scans every visible and scrollback line.

Rough memory math

Scrollback memory scales with lines × columns × tabs. Twenty tabs at 10,000 lines hold far more in memory than two tabs at 50,000. If memory is tight, reduce the line count before you reduce the number of tabs.

Many Concurrent Sessions

Every open SSH, Telnet, or SFTP tab is a live connection held by the Local Agent, plus its scrollback buffer in the UI. There is no hard cap on tab count, so resource use scales with how many sessions you keep open. Heavy multi-tab and multi-send users feel this first.

Practical guidance

Close tabs you are done with rather than leaving dozens connected. Each idle session still holds a socket, keepalive timers, and its buffer.
Use multi-send to fan a command across a group instead of manually keeping many tabs hot just to run the same line.
Tune keepalive interval (default 30 s) per profile. Very aggressive keepalives across many sessions add background traffic and wakeups; the default is fine for almost everyone.

Background tasks are capped at 3

Long-running background work (discovery jobs, scripted tasks) runs through a task registry that allows up to 3 concurrent tasks. Additional tasks queue rather than all running at once, which keeps the agent from saturating your CPU.

AI Streaming & CPU Load

The AI assistant streams responses over server-sent events from the Local Agent. Before any terminal output is sent to a model, an output sanitizer strips secrets, and the relevant knowledge packs are assembled into context. Both of those run on your CPU, so an active AI session adds load on top of your normal terminal work.

What costs CPU

Streaming a long response while you are also pushing fast output through terminals.
Large context assembly — big captured output plus several knowledge packs injected per request.
Local model providers (if you point the AI at a local LLM endpoint), where inference itself competes for CPU/GPU with the app.

If AI usage makes everything sluggish

Send less context: trim what you attach to a prompt rather than handing the model an entire 10,000-line scrollback.
Prefer a hosted model provider over a local one if your machine is the bottleneck, or vice-versa if your network is.
AI streaming is asynchronous and should not block your keystrokes; if typing stalls while AI runs, the symptom is CPU saturation, not the terminal itself. Watch the NetStacks process in your OS activity monitor to confirm.

Right-size the model

Choosing a faster, smaller model in the LLM configuration usually has a bigger effect on perceived speed than any terminal tuning, because most of the wait is the model generating tokens, not the app rendering them.

SFTP & Discovery

Two operations move a lot of work through the Local Agent at once: SFTP transfers and network discovery.

SFTP transfers

SFTP throughput is bounded by the SSH connection and the remote device. On low-powered network gear, the device's own CPU and flash write speed — not your workstation — are usually the limit. For large files, transfer during a quiet window and avoid running heavy AI or discovery jobs at the same time so the agent is not contending for CPU.

Network discovery

Discovery runs targets in parallel with built-in concurrency limits so it does not flood your machine or the network:

Discovery concurrencytext

Discovery concurrency (verified defaults)
  Max concurrent discovery targets .......... 10
  Max concurrent integration lookups ........ 5
  Background task slots (registry) ........... 3

Because of these limits, a discovery over a very large subnet is paced rather than instantaneous. That is intentional: it keeps the agent responsive and avoids overwhelming devices with limited management capacity. To finish faster, scope discovery to the address ranges you actually care about instead of scanning broadly.

Wide scans take time by design

A discovery is not "stuck" just because it is slow on a large range — it is processing targets in capped parallel batches. Narrow the seed range or target list if you need quicker results.

Local Database

NetStacks stores everything in a single SQLite file, netstacks.db, in your operating system's local app-data directory. It is opened in WAL mode (you will see netstacks.db-wal and netstacks.db-shm alongside it) and uses a small internal connection pool. For a single user this is almost never the cause of perceived slowness.

When the database matters

Disk space. A nearly full disk hurts SQLite (and the whole machine). The database, its WAL file, and any recordings or captures share that disk. Keep free space available.
Slow or networked storage. Running the app from a slow external/network drive can make writes feel sluggish. Use local SSD storage.
Large history. Long-accumulated session history, recordings, or discovery results grow the file over time. Prune data you no longer need.

Locate the database

Database locationbash

# Typical OS app-data locations for netstacks.db
# macOS
~/Library/Application Support/<app data dir>/netstacks.db

# Linux
~/.local/share/<app data dir>/netstacks.db

# Windows
%LOCALAPPDATA%\<app data dir>\netstacks.db

Close the app before touching the file

Never copy, move, or delete netstacks.db (or its -wal/-shm siblings) while NetStacks is running. Quit the app first to avoid corrupting the database. Back up the full set of files together.

Q&A

Q: Why does the app use a lot of memory?: A: The biggest driver is terminal scrollback. Each session keeps up to its scrollback limit (default 10,000 lines) in memory, multiplied by the number of open tabs. Lower the Scrollback Lines value in the profiles you use for high-volume output, clear noisy tabs, and close sessions you are finished with.
Q: My typing feels laggy in a session. What is wrong?: A: Check the round-trip time to the device first — most input lag is network latency, not the app. If the network is fast, look for CPU saturation on your workstation (often a local AI model or a wide discovery running at the same time). Input is not blocked by AI streaming, so if it stalls, the cause is overall CPU load.
Q: Does using the AI assistant slow down my terminals?: A: The AI pipeline (sanitizer, context assembly, streaming) runs on your CPU, so a busy AI session adds load. It runs asynchronously and should not block keystrokes, but if the CPU is fully saturated everything slows. Send less context per prompt and choose a faster model to reduce the hit.
Q: Why is network discovery slow on a big subnet?: A: Discovery deliberately caps concurrency (up to 10 targets at a time, 5 integration lookups, 3 background task slots) so it stays responsive and does not overwhelm devices. A wide scan is therefore paced. Narrow the seed range or target list to finish faster.
Q: Is SFTP transfer speed limited by NetStacks?: A: Usually not. SFTP runs over the SSH connection, and on network gear the device's CPU and flash write speed are the real limit. Transfer large files during a quiet window and avoid running AI or discovery jobs at the same time so the agent is not contending for CPU.
Q: Does NetStacks need PostgreSQL or a server to perform well?: A: No. The free Terminal is a self-contained desktop app with a local SQLite database and a Local Agent sidecar. There is no PostgreSQL, reverse proxy, or remote server to tune. Performance is about your workstation, the network, and the remote devices.
Q: Where is my data stored, and can it grow too large?: A: Everything lives in netstacks.db in your OS app-data directory (with WAL/SHM sidecar files). It can grow with long session history, recordings, and discovery results. Keep free disk space, store it on local SSD, and prune old data you no longer need. Always quit the app before backing up or moving the file.

Troubleshooting Table

Match the symptom to the most likely cause and fix.

Symptom	Likely Cause	Fix
App window sluggish, high memory	Large scrollback across many tabs	Lower Scrollback Lines per profile; clear/close noisy tabs
Typing lag in one session	Network latency to the device	Check round-trip time; it is the device/path, not the app
Everything slows when AI is active	CPU saturation from sanitizer/context/model	Send less context, pick a faster model, watch CPU in OS monitor
Discovery seems to crawl	Capped concurrency over a wide range (by design)	Narrow the seed range/target list; it is paced, not stuck
SFTP transfer is slow	Remote device CPU/flash or contention on the agent	Transfer during a quiet window; avoid concurrent AI/discovery
Sluggish writes / general slowness	Nearly full or slow (network) storage	Free up disk space; run from local SSD
Web UI freezes on very large tables	Too many DOM rows rendered at once	Use pagination / narrower filters where available

Quit before touching data files

Any maintenance that moves, copies, or deletes the database must be done with NetStacks fully closed to avoid corrupting netstacks.db and its WAL files.

Getting Started: Requirements — recommended system resources for NetStacks Terminal
Terminal: Overview — how the terminal and Local Agent work together
Terminal: Multi-Tab — managing many concurrent sessions efficiently
Terminal: SFTP — file transfer behavior and expectations
AI: LLM Configuration — choosing a model and provider that fit your machine
Devices: Network Discovery — scoping discovery and its concurrency behavior
Troubleshooting: Connection Issues — when slowness is actually a connection failure