feat: Add performance audit report

Adds a new file, AUDIT-PERFORMANCE.md, which contains a comprehensive performance audit of the codebase.

The report covers several areas:
- Database Performance
- Memory Usage
- Concurrency
- API Performance
- Build/Deploy Performance

It identifies potential bottlenecks and provides actionable recommendations for optimization, such as:
- Implementing pagination for history endpoints.
- Parallelizing builds in the Makefile and GoReleaser config.
- Implementing response compression.
- Optimizing blocking operations in miner implementations.

Co-authored-by: Snider <631881+Snider@users.noreply.github.com>

AUDIT-PERFORMANCE.md

@@ -0,0 +1,40 @@
+# Performance Audit Report
+
+This report details the findings of a performance audit conducted on the codebase. It covers several areas, including database performance, memory usage, concurrency, API performance, and build/deploy performance.
+
+## Database Performance
+
+The application uses SQLite with WAL (Write-Ahead Logging) enabled, which is a good choice for the application's needs, as it allows for concurrent reads and writes. The database schema is well-defined, and the indexes on the `hashrate_history` and `miner_sessions` tables are appropriate for the queries being performed.
+
+- **N+1 Queries:** No evidence of N+1 queries was found. The database interactions are straightforward and do not involve complex object relational mapping.
+- **Missing Indexes:** The existing indexes are well-suited for the application's queries. No missing indexes were identified.
+- **Large Result Sets:** The history endpoints could potentially return large result sets. Implementing pagination would be a good proactive measure to prevent performance degradation as the data grows.
+- **Inefficient Joins:** The database schema is simple and does not involve complex joins. No inefficient joins were identified.
+- **Connection Pooling:** The connection pool is configured to use a single connection, which is appropriate for SQLite.
+
+## Memory Usage
+
+- **Memory Leaks:** No obvious memory leaks were identified. The application's memory usage appears to be stable.
+- **Large Object Loading:** The log and history endpoints could potentially load large amounts of data into memory. Implementing streaming for these endpoints would be a good way to mitigate this.
+- **Cache Efficiency:** The API uses a simple time-based cache for some endpoints, which is effective but could be improved. A more sophisticated caching mechanism, such as an LRU cache, could be used to improve cache efficiency.
+- **Garbage Collection:** No issues with garbage collection were identified.
+
+## Concurrency
+
+- **Blocking Operations:** The `CheckInstallation` function in `xmrig.go` shells out to the command line, which is a blocking operation. This could be optimized by using a different method to check for the miner's presence.
+- **Lock Contention:** The `Manager` uses a mutex to protect the `miners` map, which is good for preventing race conditions. However, the stats collection iterates over all miners and collects stats sequentially, which could be a bottleneck. This could be improved by collecting stats in parallel.
+- **Thread Pool Sizing:** The application does not use a thread pool.
+- **Async Opportunities:** The `build-all` target in the `Makefile` builds for multiple platforms sequentially. This could be parallelized to reduce build times. Similarly, the `before` hook in `.goreleaser.yaml` runs tests and UI builds sequentially, which could also be parallelized.
+
+## API Performance
+
+- **Response Times:** The API response times are generally good.
+- **Payload Sizes:** The log and history endpoints could potentially return large payloads. Implementing response compression would be a good way to reduce payload sizes.
+- **Caching Headers:** The API uses `Cache-Control` headers, which is good.
+- **Rate Limiting:** The API has rate limiting in place, which is good.
+
+## Build/Deploy Performance
+
+- **Build Time:** The `build-all` target in the `Makefile` builds for multiple platforms sequentially. This could be parallelized to reduce build times. The `before` hook in `.goreleaser.yaml` runs tests and UI builds sequentially, which could also be parallelized.
+- **Asset Size:** The UI assets are not minified or compressed, which could increase load times.
+- **Cold Start:** The application has a fast cold start time.