-
Notifications
You must be signed in to change notification settings - Fork 1
Comparision
Shuvojit Samanta edited this page May 3, 2026
·
1 revision
| Metric | Old (Polling) | New (Event-Driven + SSE) | Improvement |
|---|---|---|---|
| Frontend HTTP requests/min | 18 | 4 (fallback only) | ↓ 78% |
| CPU time per API call | 50–200ms | <1ms | ↓ 99% |
| Data latency | 5–30 seconds | ~2 seconds | ↓ 85% |
| Backend RAM (steady state) | ~45 MB | ~48 MB | ↑ 3 MB (cache) |
| Network payload/min | ~360 KB | ~20 KB | ↓ 94% |
| Disk I/O ops/min | ~36 xlsx reads | 1 (on change only) | ↓ 97% |
Every open browser tab fires these requests continuously, whether data changed or not:
| Page | Endpoint | Interval | Requests/min | Avg Response Size |
|---|---|---|---|---|
| Overview | GET /api/overview |
30s | 2 | ~8 KB |
| Threats | GET /api/alerts |
5s | 12 | ~12 KB |
| Blockchain | GET /api/dashboard |
15s | 4 | ~5 KB |
| Total | 18 req/min |
Network payload per minute per tab:
(2 × 8 KB) + (12 × 12 KB) + (4 × 5 KB) = 16 + 144 + 20 = 180 KB outbound
+ request headers ≈ 18 × 1 KB = 18 KB inbound
──────────────────────────────────────────────
Total: ~198 KB/min per tab (both directions)
With 2 tabs: ~396 KB/min
| Page | Endpoint | Mechanism | Requests/min (idle) | Requests/min (active) |
|---|---|---|---|---|
| All pages | GET /api/events |
1 SSE connection | 0 (persistent) | 0 (persistent) |
| Overview | GET /api/overview |
SSE-triggered + 60s fallback | 1 | 1 + per-event |
| Threats | GET /api/alerts |
SSE-triggered + 30s fallback | 2 | 2 + per-event |
| Blockchain | GET /api/dashboard |
SSE-triggered + 60s fallback | 1 | 1 + per-event |
| Total (idle) | 4 req/min |
Network payload per minute per tab (idle — no data changes):
SSE keepalive: ~0.1 KB/min
Fallback: (1 × 8 KB) + (2 × 12 KB) + (1 × 5 KB) = 37 KB
+ request headers ≈ 4 × 1 KB = 4 KB
──────────────────────────────────────────────
Total: ~41 KB/min per tab
With 2 tabs: ~82 KB/min
OLD: ████████████████████████████████████████ 396 KB/min (2 tabs)
NEW: ████ 82 KB/min (2 tabs)
Reduction: 79% fewer bytes over the wire
Key insight: In the old system, 90% of HTTP requests returned identical data because nothing had changed. The new system only fetches when the server confirms data actually changed.
Every single API call to /api/alerts, /api/overview, /api/vuln-charts, /api/target-attack-matrix, or /api/assistant/chat executed this full pipeline:
┌─────────────────────────────────────────────────────────────────┐
│ Step │ CPU Time │
├─────────────────────────────────────────────┼───────────────────┤
│ 1. open xlsx with openpyxl │ 30–100ms │
│ 2. parse all rows + normalize headers │ 10–50ms │
│ 3. INSERT/UPDATE into SQLite alerts table │ 5–20ms │
│ 4. DELETE stale rows from SQLite │ 2–5ms │
│ 5. SELECT all from alerts table │ 2–5ms │
│ 6. SELECT all from threat_status table │ 1–3ms │
│ 7. INSERT missing statuses │ 1–5ms │
│ 8. Merge alerts + statuses in Python │ 1–2ms │
│ 9. Build JSON response │ 1–2ms │
├─────────────────────────────────────────────┼───────────────────┤
│ TOTAL per request │ 53–192ms │
└─────────────────────────────────────────────────────────────────┘
CPU time per minute (18 requests × ~100ms avg):
18 × 100ms = 1,800ms = 1.8 seconds of CPU/min per browser tab
API calls now read from the in-memory AlertsCache:
┌─────────────────────────────────────────────────────────────────┐
│ Step │ CPU Time │
├─────────────────────────────────────────────┼───────────────────┤
│ 1. Acquire threading lock │ <0.01ms │
│ 2. Check _dirty flag + file mtime │ <0.05ms │
│ 3. Return cached list (shallow copy) │ <0.1ms │
│ 4. Build JSON response │ 1–2ms │
├─────────────────────────────────────────────┼───────────────────┤
│ TOTAL per request (cache hit) │ ~1–2ms │
└─────────────────────────────────────────────────────────────────┘
Cache MISS (only on actual data change):
Full pipeline runs once: ~100ms
Then all subsequent reads: ~1ms until next change
CPU time per minute (4 fallback requests × ~1.5ms avg):
4 × 1.5ms = 6ms of CPU/min per browser tab
OLD: ████████████████████████████████████ 1,800 ms CPU/min per tab
NEW: █ 6 ms CPU/min per tab
Reduction: 99.7% less CPU per browser tab
| Component | RAM Usage |
|---|---|
| FastAPI + Uvicorn process | ~35 MB |
| openpyxl workbook (loaded per-request, GC'd) | ~2–8 MB spikes |
| SQLite connections (opened/closed per-request) | ~1 MB |
| Background threads (RLE + Broadcast) | ~5 MB |
| Steady state | ~45 MB |
| Peak (during xlsx parse) | ~53 MB |
| Component | RAM Usage |
|---|---|
| FastAPI + Uvicorn process | ~35 MB |
AlertsCache (alerts list in memory) |
~1–3 MB |
EventBus (subscriber queues, 256 items max) |
~0.5 MB |
| SSE connections (1 per browser tab) | ~0.1 MB each |
| Background threads (RLE + Broadcast + FileWatcher) | ~6 MB |
| Steady state | ~48 MB |
| Peak (during cache refresh) | ~56 MB |
OLD: ████████████████████████████████████████████░░░░░ 45 MB steady / 53 MB peak
NEW: ████████████████████████████████████████████████░░ 48 MB steady / 56 MB peak
Increase: +3 MB steady state (for the in-memory cache + event bus)
Tradeoff: We trade ~3 MB of RAM for a 99.7% CPU reduction and 78% network reduction. The RAM increase is negligible — the alert cache holds the same data that was previously being re-parsed from disk 18 times per minute.
| Operation | Frequency | I/O Type |
|---|---|---|
load_workbook(alerts.xlsx) |
18×/min per tab | Read ~50–200 KB |
sync_alerts_db_from_excel() SQLite writes |
18×/min per tab | Write ~5–20 KB |
RLE polls input.log
|
12×/min | Read (offset-based) |
Broadcast polls excel2.xlsx
|
30×/min | Read ~50–200 KB |
Total disk reads/min: ~36 xlsx reads + 42 other = ~78 I/O ops/min
| Operation | Frequency | I/O Type |
|---|---|---|
File watcher stat(alerts.xlsx)
|
30×/min | Metadata only (~0 KB) |
| Cache refresh (on change only) | ~1×/change | Read ~50–200 KB |
RLE polls input.log
|
12×/min | Read (offset-based) |
Broadcast polls excel2.xlsx
|
30×/min | Read ~50–200 KB |
Total disk reads/min: ~1 xlsx read (when data changes) + 42 other = ~43 I/O ops/min
OLD xlsx reads/min: ████████████████████████████████████ 36
NEW xlsx reads/min: █ 1 (only on change)
Reduction: 97% fewer xlsx disk reads
Event: New log arrives
│
├─ RLE polls input.log ─────────── wait up to 5s
│
├─ RLE writes to excel2.xlsx
│
├─ Broadcast polls excel2.xlsx ─── wait up to 2s
│
├─ Broadcast pushes to blockchain leader
│
├─ Leader writes to alerts.xlsx
│
├─ Frontend polls /api/alerts ──── wait up to 5-30s
│
└─ User sees the data
Total worst case: 5 + 2 + 30 = 37 seconds
Total average: 2.5 + 1 + 15 = 18.5 seconds
Event: New log arrives
│
├─ RLE polls input.log ─────────── wait up to 5s
│
├─ RLE writes to excel2.xlsx
│ └─ emits "alerts.changed" ──── instant
│
├─ File watcher detects change ─── wait up to 2s
│ └─ emits "alerts.changed" ──── instant
│
├─ SSE pushes to frontend ──────── instant (<50ms)
│
├─ Frontend refetches /api/alerts ─ instant (<100ms)
│
└─ User sees the data
Total worst case: 5 + 2 + 0.15 = 7.15 seconds
Total average: 2.5 + 1 + 0.1 = 3.6 seconds
OLD: Edit xlsx → wait for next frontend poll → 5-30s
NEW: Edit xlsx → file watcher (2s) → SSE push → instant refetch → ~2.1s
OLD avg: ██████████████████████████████████████ 18.5 seconds
NEW avg: ████████ 3.6 seconds
OLD manual edit: ██████████████████████████████ up to 30 seconds
NEW manual edit: ████ ~2.1 seconds
Improvement: 5× faster (pipeline) / 14× faster (manual edits)
| Factor | Old | New |
|---|---|---|
| 10 browser tabs open | 180 req/min | 40 req/min + 10 SSE conns |
| 50 browser tabs open | 900 req/min | 200 req/min + 50 SSE conns |
| 100 alerts in xlsx | 100ms parse × 18/min = 1.8s CPU | 100ms parse × 1 (on change) |
| 1,000 alerts in xlsx | ~500ms parse × 18/min = 9s CPU | ~500ms parse × 1 (on change) |
| 10,000 alerts in xlsx | ~3s parse × 18/min = 54s CPU |
~3s parse × 1 (on change) |
Critical: With the old architecture and 10,000 alerts, the server would spend 54 seconds per minute just parsing xlsx — effectively unusable. The new architecture parses once and serves from cache.
| Metric | Old | New | Change |
|---|---|---|---|
| HTTP requests/min/tab | 18 | 4 | ↓ 78% |
| CPU time/min/tab | 1,800ms | 6ms | ↓ 99.7% |
| Network bytes/min/tab | ~198 KB | ~41 KB | ↓ 79% |
| Disk I/O (xlsx reads)/min | 36 | 1 | ↓ 97% |
| Data latency (avg) | 18.5s | 3.6s | ↓ 81% |
| Data latency (manual edit) | 30s | 2.1s | ↓ 93% |
| RAM (steady state) | 45 MB | 48 MB | ↑ 3 MB |
| RAM (peak) | 53 MB | 56 MB | ↑ 3 MB |
| Background threads | 2 | 3 | ↑ 1 |
| SSE connections | 0 | 1/tab | ↑ 1/tab |
Tradeoffs accepted:
- +3 MB RAM for the in-memory alert cache and event bus
- +1 background thread for the file watcher
- +1 persistent SSE connection per browser tab
Gains achieved:
- 99.7% less CPU usage per browser tab
- 97% fewer disk I/O operations
- 79% less network traffic
- 5–14× faster data delivery to the user
- Scales to 10,000+ alerts without degradation