Spranz Management Tool - Performance Analysis

Overview

Server: designer.spranz.de (23.88.122.78, Hetzner) SSH: ssh spranz-live (adminwayne key) Tool path: /var/www/designer.spranz.de/managementtool/ (aliased to /spranzmanagementtool/ in nginx) Dev Project: PROJ-2026-0053

This page documents a performance investigation conducted on 13 March 2026, based on nginx access log analysis covering 27 Feb – 13 Mar 2026 (161,253 total requests), plus the deployment of a live performance monitoring dashboard.

---

Deployed: Performance Dashboard

A live monitoring dashboard was deployed at:

https://designer.spranz.de/spranzmanagementtool/perf-dashboard/

It is also accessible via the ⏱ .perf button in the tool’s navigation bar.

What it tracks

Event	Description
page.load	Full page load time with TTFB, DNS, connect, transfer breakdown
page.dom_ready	DOMContentLoaded time
api.*	Every SpranzTool.fetchApi() call, auto-timed
thumbnails.batch	Batch stats every 50 thumbnails (avg/min/max ms)
thumbnails.complete	Final thumbnail summary on page leave (total, avg, p95)

Deployed files

File	Purpose
managementtool/api/perf-log.php	Accepts batched events via sendBeacon, writes to logs/perf-YYYY-MM-DD.jsonl
managementtool/assets/js/perf.js	Client-side monitor, loads on every page
managementtool/perf-dashboard/index.php	Dashboard UI with Chart.js, auto-refreshes every 15s
managementtool/includes/header.php	Patched to load perf.js and expose .perf nav link

---

Issues Found

🔴 Critical: PostgreSQL auth failure on every editor load

Affects every editor page load

editor/index.php line 15 calls pg_connect() to a local PostgreSQL on port 5432 with credentials that always fail. This error appears in every single nginx error log entry for the editor.

pg_connect(): Unable to connect to PostgreSQL server —
FATAL: password authentication failed for user "postgres"
in /var/www/designer.spranz.de/managementtool/editor/index.php on line 15

The editor still functions (falls back to file-based storage), but the failed connection attempt adds latency on every load.

Fix: Correct the PostgreSQL credentials in editor/index.php line 15, or remove the pg_connect() call if local DB is not used on this server.

---

🔴 Critical: save-project.php returning HTTP 500 (61 errors)

Users lost work

61 × HTTP 500 from 2dtool/api/save-project.php. On 9 March 2026, 40+ errors occurred in a 2-hour window (06:46–11:28), meaning users were actively failing to save during that session.

Timeline of 500 errors:

Date	Count	Window
3 Mar	1	20:39
5 Mar	1	15:59
6 Mar	10	08:22–14:15
9 Mar	40+	06:46–11:28
11 Mar	7	13:27–13:46
12 Mar	2	(update/add technique)

Response body is only 56 bytes — a short error message. The error handling in save-project.php needs investigation, likely a database write failure.

---

🟠 High: load-project.php serving files up to 28 MB

Major editor slowness

Project files are served as full JSON/SVG on every open, with no compression or lazy loading.

SKU	Response size	Times loaded
9323-00.001	28.3 MB	1
382-69.001	10.8 MB	7×
101-56.001	9.6 MB	1
3391-00.028	7.5 MB	4×
426-AB.001	6.9 MB	5×
377-00.004	5.4 MB	2×

Fix options:

• Enable gzip compression on the endpoint (quick win)
• Split large SVG projects into lazy-loaded layers
• Store project data normalised rather than as a single JSON blob

---

🟠 High: log-frontend.php = 67% of all traffic

Excessive server load

108,900 of 161,253 total requests (67%) are hits to 2dtool/api/log-frontend.php. This is a client-side error/event logging endpoint being called on every user interaction in the 2dtool.

Fix: Batch log calls (debounce/queue), add rate limiting, or reduce logging verbosity in production (SpranzTool.config.debug = false).

---

🟡 Medium: Thumbnail loading — 47 client timeouts (HTTP 499)

The pdf-browser loads all 619 thumbnails simultaneously with no lazy loading. The browser fires 619 individual requests to pdf-thumbnail.php on page load, saturating the server. On 47 occasions the browser gave up waiting (HTTP 499).

Fix: Use IntersectionObserver to only load thumbnails as they scroll into view. Already partially instrumented in perf.js — the dashboard will show real batch timing data once usage accumulates.

---

🟡 Medium: Missing PDF files (404)

Several PDFs are referenced but missing from disk:

File	Notes
101-16.001.pdf	—
245-58.001.pdf	—
775-00.001neu.pdf	File exists as 775-00.001Neu.pdf — case mismatch
6309-00.001.pdf	—
3391-00.001.pdf	—
6350-00.001.pdf	—
522-00.001.pdf	—
371-00.001.pdf	—

The 775-00.001neu.pdf case mismatch suggests a naming convention issue. Linux filesystems are case-sensitive.

---

Traffic Overview (27 Feb – 13 Mar 2026)

Metric	Value
Total requests	161,253
HTTP 200	128,661 (80%)
HTTP 304 (not modified)	32,411 (20%)
HTTP 500	69
HTTP 499 (client timeout)	64
HTTP 404	43

Top endpoints by hits

Endpoint	Hits
2dtool/api/log-frontend.php	108,900
api/pdf-thumbnail.php	41,384
2dtool/api/save-svg-2d.php	1,710
2dtool/api/project-api.php	1,077
editor/api/upload-pdf-convert.php	431
editor/api/load-project.php	252
editor/api/create-pdf-fast.php	190

---

Recommended Fix Priority

1. Fix PostgreSQL credentials in editor/index.php:15 — low effort, removes error noise on every load
2. Investigate save-project.php 500 errors — users are losing work
3. Enable gzip on load-project.php — quick win for large project files
4. Lazy-load thumbnails in pdf-browser — fixes the 619-request flood
5. Reduce log-frontend.php call frequency in 2dtool — reduces 67% of server load
6. Fix PDF filename casing — at minimum fix 775-00.001neu → 775-00.001Neu