Performance and limits

Performance and limits

Knot runs on your Dolibarr server: performance depends on CPU, MariaDB/MySQL, and overall ERP load. This page summarizes good practices and signals to watch.

Default limits (order of magnitude)

Exact values may change with Knot Core releases; tune them in admin settings when your host allows it.

Area	Typical behavior
Concurrency	Multiple runs may coexist; locks prevent conflicts on the same workflow.
Node timeout	HTTP and AI connectors have a maximum duration; overrun marks the run as failed.
Cron	A Cron trigger does not backfill long outages — monitor Dolibarr cron health.
History	Old runs may be purged per retention policy (see Knot admin).

Optimize a workflow

1. Fewer nodes — merge redundant HTTP or Dolibarr steps.
2. Filter early — use Logic (If) before costly steps (AI, bulk exports).
3. Limit loops — avoid scanning thousands of rows without Dolibarr pagination.
4. Credentials — resolve once per run when possible.
5. Simulate before activation to measure dry-run duration.

Database and Dolibarr

• MariaDB/MySQL indexes and maintenance affect Dolibarr nodes.
• ERP peaks (closing, imports) slow every module, including Knot.

Dashboard

The Knot dashboard (inside Dolibarr) shows recent run volume, failures, and average duration. Use it to spot regressions after a business change.

When to tune hardware or the server

• Runs consistently near timeout with minimal logic.
• Growing queue during business hours.
• Disk or RAM saturation on the Dolibarr VM.

Nota

The shared demo is not representative of production performance: multi-tenant instance and abuse quotas.

See also

• Connector error — timeouts and 503 responses.
• In-repo admin docs (core/docs/) for advanced administrator-only settings.