Blog

About the Recent Slowdown

If Grampshub felt sluggish in the past few days, with slow page loads and background tasks taking far longer than usual, this post explains what happened.

The short version

An automated program sent a large number of requests to a rarely used part of the Gramps Web API, in a way that made each request far more demanding than necessary. The resulting strain on the database server that all trees share lingered for several days, until a restart of the database on September 21 cleared the accumulated load.

Everything is running normally again. No data was lost, and there is nothing you need to do. Normal use of Grampshub could not have caused this.

Timeline

• Night of September 14–15: A burst of automated requests sharply increases the load on the database.
• September 15–20: Grampshub is slow at times, and some background tasks take much longer than they should.
• September 20: An update to Gramps Web API that prevents this problem is released and installed on Grampshub.
• September 21: A restart of the database clears the accumulated load, and performance is back to normal.

What happened

Gramps Web has a special function for applying a whole batch of changes at once. It is meant for the Gramps Web Sync addon, which synchronizes desktop Gramps with Gramps Web. The web app in your browser never uses it.

When this function is used as intended, the expensive part of the work, updating the search index, is set aside and done later. The automated program skipped that step, so every request did all of the work immediately and kept the database busy while doing so. It sent a large burst of these requests overnight, most likely from a script or AI agent. Some requests took so long that the server cut them off halfway, which left the database with work it could not tidy up. Over time, this slowed down everything else on the same server.

What has changed

The Gramps Web API update released on September 20 always sets the expensive work aside, regardless of how the function is called. The kind of request that caused this slowdown is now as light as any other.

On the Grampshub side, the database now stops stalled requests much sooner, so a single misbehaving program cannot build up this kind of load again.

Automated access remains welcome

Your data on Grampshub is meant to be accessible, and that includes accessing it with your own scripts and AI agents. This will not be blocked. The one request is that automated tools pace themselves, since a program running in a tight loop affects everyone on the server, not only its own account.

For developers

The endpoint involved is /transactions/, a replay mechanism for sync clients. Called without background, it used to update the semantic search index within the request, holding a database transaction open. Gramps Web API 3.22.1 no longer blocks in that case (PR #990), and the documentation now describes the endpoint’s purpose (PR #991).

If you are building a client for the Gramps Web API, please send an identifiable User-Agent header. It makes a well-behaved client quick to rule out when something like this happens. There is more context in this discussion on the Gramps forum.

Thanks to everyone who reported the slowdown. It made tracking this down much faster.