mirror of
https://github.com/jokob-sk/NetAlertX.git
synced 2025-12-07 09:36:05 -08:00
97 lines
3.9 KiB
Markdown
Executable File
97 lines
3.9 KiB
Markdown
Executable File
# Performance Optimization Guide
|
||
|
||
There are several ways to improve the application's performance. The application has been tested on a range of devices, from a Raspberry Pi 4 to NAS and NUC systems. If you are running the application on a lower-end device, carefully fine-tune the performance settings to ensure an optimal user experience.
|
||
|
||
## Common Causes of Slowness
|
||
|
||
Performance issues are usually caused by:
|
||
|
||
- **Incorrect settings** – The app may restart unexpectedly. Check `app.log` under **Maintenance → Logs** for details.
|
||
- **Too many background processes** – Disable unnecessary scanners.
|
||
- **Long scan durations** – Limit the number of scanned devices.
|
||
- **Excessive disk operations** – Optimize scanning and logging settings.
|
||
- **Failed maintenance plugins** – Ensure maintenance tasks are running properly.
|
||
|
||
The application performs regular maintenance and database cleanup. If these tasks fail, performance may degrade.
|
||
|
||
### Database and Log File Size
|
||
|
||
A large database or oversized log files can slow down performance. You can check database and table sizes on the **Maintenance** page.
|
||
|
||

|
||
|
||
> [!NOTE]
|
||
> - For **~100 devices**, the database should be around **50MB**.
|
||
> - No table should exceed **10,000 rows** in a healthy system.
|
||
> - These numbers vary based on network activity and settings.
|
||
|
||
---
|
||
|
||
## Maintenance Plugins
|
||
|
||
Two plugins help maintain the application’s performance:
|
||
|
||
### **1. Database Cleanup (DBCLNP)**
|
||
- Responsible for database maintenance.
|
||
- Check settings in the [DB Cleanup Plugin Docs](/front/plugins/db_cleanup/README.md).
|
||
- Ensure it’s not failing by checking logs.
|
||
- Adjust the schedule (`DBCLNP_RUN_SCHD`) and timeout (`DBCLNP_RUN_TIMEOUT`) if needed.
|
||
|
||
### **2. Maintenance (MAINT)**
|
||
- Handles log cleanup and other maintenance tasks.
|
||
- Check settings in the [Maintenance Plugin Docs](/front/plugins/maintenance/README.md).
|
||
- Ensure it’s running correctly by checking logs.
|
||
- Adjust the schedule (`MAINT_RUN_SCHD`) and timeout (`MAINT_RUN_TIMEOUT`) if needed.
|
||
|
||
---
|
||
|
||
## Scan Frequency and Coverage
|
||
|
||
Frequent scans increase resource usage, network traffic, and database read/write cycles.
|
||
|
||
### **Optimizations**
|
||
- **Increase scan intervals** (`<PLUGIN>_RUN_SCHD`) on busy networks or low-end hardware.
|
||
- **Extend scan timeouts** (`<PLUGIN>_RUN_TIMEOUT`) to prevent failures.
|
||
- **Reduce the subnet size** – e.g., from `/16` to `/24` to lower scan loads.
|
||
|
||
Some plugins have additional options to limit the number of scanned devices. If certain plugins take too long to complete, check if you can optimize scan times by selecting a scan range.
|
||
|
||
For example, the **ICMP plugin** allows you to specify a regular expression to scan only IPs that match a specific pattern.
|
||
|
||
---
|
||
|
||
## Storing Temporary Files in Memory
|
||
|
||
On systems with slower I/O speeds, you can optimize performance by storing temporary files in memory. This primarily applies to the `/app/api` and `/app/log` folders.
|
||
|
||
Using `tmpfs` reduces disk writes and improves performance. However, it should be **disabled** if persistent logs or API data storage are required.
|
||
|
||
Below is an optimized `docker-compose.yml` snippet:
|
||
|
||
|
||
```yaml
|
||
version: "3"
|
||
services:
|
||
netalertx:
|
||
container_name: netalertx
|
||
# Uncomment the line below to test the latest dev image
|
||
# image: "ghcr.io/jokob-sk/netalertx-dev:latest"
|
||
image: "jokobsk/netalertx:latest"
|
||
network_mode: "host"
|
||
restart: unless-stopped
|
||
volumes:
|
||
- local/path/config:/app/config
|
||
- local/path/db:/app/db
|
||
# (Optional) Useful for debugging setup issues
|
||
- local/path/logs:/app/log
|
||
# (API: OPTION 1) Store temporary files in memory (recommended for performance)
|
||
- type: tmpfs # ◀
|
||
target: /app/api # ◀
|
||
# (API: OPTION 2) Store API data on disk (useful for debugging)
|
||
# - local/path/api:/app/api
|
||
environment:
|
||
- TZ=Europe/Berlin
|
||
- PORT=20211
|
||
|
||
```
|