I suspect the performance issues are due to Toolforge resource limits. Stalktoy is very quick right after a restart, but it slows significantly when many connections are using it simultaneously. Stalktoy is already running on its own account with no other tool, so I'm not sure what else I can do as a Toolforge user to avoid hitting the limits. (Pull requests are always welcome if someone spots something that could be optimized though.)

NB : here is the message when I try to connect :

upstream connect error or disconnect/reset before headers. reset reason: connection termination

Hey @Pathoschild , do you know what are the performances limits that have been hit by the tool?
Perhaps there may be entries in the logs that might indicate, for example, that it get killed, or memory-related issues? Does the tool shut down and restart regularly, or does it just hang there unresponsive until a maintainer reboots it?
By identifying what's causing the problem, we should be able to request that the default Toolforge limit be increased.

Stalktoy runs by itself on the meta3 account.

When the issue happens, requests begin taking a very long time to complete (even trivial requests like loading an empty form). At that point, the tool's lighttpd status page typically shows many connections in 'handle-req' mode:

300 connections
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

0	  k = keep-alive
0	  . = connect
0	  q = req-start
0	  r = read
0	  Q = req-end
0	  R = readpost
300	  h = handle-req
0	  s = resp-start
0	  W = write
0	  S = resp-end
0	  E = error
0	  C = close

The delay seems to happen before the request is received by the tool code:

• Even the status page added by the mod_status server module is affected, so it doesn't seem to be an issue limited to the tool code itself.
• Stalktoy tracks the time needed to process a request (shown at the bottom of the page). For an empty form load I just tested, it took several minutes to load but <1 second of actual tool code processing time.

The error log shows an endless series of these errors:

2026-07-16 20:04:51: (server.c.1089) [note] sockets disabled, connection limit reached
2026-07-16 20:04:51: (server.c.1081) [note] sockets enabled again
2026-07-16 20:04:51: (server.c.1089) [note] sockets disabled, connection limit reached
2026-07-16 20:04:52: (server.c.1081) [note] sockets enabled again
2026-07-16 20:04:52: (server.c.1089) [note] sockets disabled, connection limit reached
2026-07-16 20:04:58: (server.c.1081) [note] sockets enabled again
2026-07-16 20:04:58: (server.c.1089) [note] sockets disabled, connection limit reached

I'm not sure whether that connection limit is the cause, or a symptom of a different limit getting hit which results in connections piling up. But once the issue starts, a death spiral ensues (requests take longer → connections pile up → requests take even longer → connections pile up even more).

According to the statistics, this tool records more than 10,000 page views per day, with peaks of up to 70,000.
Twoyears ago, this figure was a tenth of that; this is therefore likely to be the root cause.
The global issue to track bot abuse on toolforge is T226688: Block web crawlers from accessing Cloud Services but it hasn't any useful solutions yet.

Some tools implement simple anti-bot measures, such as adding a function at the start of all server responses that checks whether the visitor has a cookie; if it doesn't, a page is displayed containing a snippet of JavaScript code that sets this cookie. It avoids huge compute on bot page loads.

Adding cloud-services-team in case they've more up-to-date tips to block crawlers on individual tools or a global solution for the platform.

In T427941#11992005, @Pathoschild wrote:

I'm not sure what else I can do as a Toolforge user to avoid hitting the limits.

One sort of annoying, but generally effective, tactic is to put a login wall up before hitting the databases. This is a thing that XTools for example has added to various high cost pages to keep bots out.