Xyren XYREN
← All update notes
tooling performance backups

Updates April 5th — Observability, backups, and a perf sweep

Horizon, Telescope, and Pulse are wired up. Automated backups run twice a day. Sessions moved to Redis and a leaky scheduler got shot in the head.

A
Austen Green
Author

Hello everyone!

Not the most glamorous update, but the one that makes everything else reliable. This month the dashboard grew a proper dev-tools drawer and a backup pipeline, and I fixed a slow-motion connection leak that had been making the database sweat.

Dev Tools

The top nav now has a separate "Dev Tools" dropdown next to Admin. The split is intentional — Admin is for things you do to users, Dev Tools is for things you do to the server. Under the hood they share a single config array now, so adding a new page to either section is a one-line edit.

In the Dev Tools drawer:

All three are pinned to the admin 2FA gate so only signed-in staff can see them.

Backups

There's a Backups page now. It ships a twice-daily mysqldump (06:00 and 23:00), gzips the output, and retains the last 14 files. You can also lock a specific backup from the UI to pin it forever — handy before a risky migration.

The page shows each backup's filename, size, timestamp, and status, with download and lock/unlock buttons. On mobile it collapses into a card list; no horizontal scrolling.

The perf sweep

This is the technical section — feel free to skip this if you aren't interested.

Two things were dragging the app down:

First, sessions were stored in MySQL. That meant every authenticated request did a session read, a session write, and a database round-trip for each of those. Sessions are now in Redis, which is what they should have been from day one.

Second, there was a pulse:check scheduler entry that was supposed to run every minute. It was long-running — as in, each invocation lasted longer than sixty seconds — so new invocations were stacking on top of old ones, each of them holding an open MySQL connection and never releasing it. After a few days of uptime the connection count would drift close to max_connections=151 and anything else wanting a DB connection would start erroring out.

Fix was two-part: drop the stacking scheduler entry entirely (it was a leftover from an earlier experiment), and bump max_connections to 500 to give us headroom. No more Too many connections on a busy afternoon.

Smaller cleanups

force-signout and force-reset-password no longer assume the session driver — they work whether sessions live in Redis, the database, or cookies. db:backup now excludes the big log tables (telescope entries, pulse entries) from routine backups so the gzip doesn't balloon.

Changelog

So what's next? Next one's more fun — a live game-data editor, an item-icon editor pulling sprites straight from the game cache, and a real-terrain world map with live player dots.

All the best, Austen