What I’m trying to do:
Run background server script that took 16 to 55 secs yesterday - depending on load, I guess. This morning it needs 1248 secs, 50 to 100 times slower
What I’ve tried and what’s not working:
Maintenance work?
Hobby vs Business Plan?
Faster on my own VPS?
Thanks and best
Solved - had a lost (?) breakpoint somewhere deep in the code.
1 Like
Yes, the simple existence of a breakpoint could be a very unintuitive reason for major slow downs.
See here: [Done] [Debugger] Add a "Clear all breakpoints" button
1 Like
Yeah, this can happen when you’re running something:
- In your debug environment
- Without the Anvil Editor open for that app
- In the background (BG task, HTTP endpoint, handling incoming email, etc)
- With enabled breakpoints
The reason is this: The debug environment is meant to be used while you have that app open in the Anvil Editor – that’s the point; it’s so you can see your changes immediately. However, when we hit a breakpoint in the middle of a BG task or HTTP endpoint on the server, it’s not immediately associated with a particular Anvil Editor session. So how do we open the Debugger tab for you?
The way we end up doing it is to have the code pause at the breakpoint, then signal to any connected instances of the Anvil Editor that currently have that app open. If those Editors are actually alive (ie they’re not zombie connections left over after someone shut their laptop), they will wake up, open the Debugger tab, talk to the debug machinery, establish a connection to the back-end code, and we’re off to the races. If there are no live Editors, however, we mustn’t leave that code paused forever!
So we compromise: When we stop at a server-side breakpoint, we wait for a couple of seconds. If, in that couple of seconds, we haven’t heard from the Editor, we assume that there are no Editors waiting to handle the breakpoint, and resume execution. (If we do hear from an Editor, we keep sending keepalives back and forth for as long as we’re paused at that breakpoint. If the user drops off the Internet or closes their laptop and we stop hearing from that Editor, we will time out and resume execution.)
The end result is that if you manage to meet all the criteria above, your background task will keep trying to stop at a breakpoint, waiting for a couple of seconds, then timing out and continuing execution. If you’ve got your breakpoint in a tight loop, those pauses will really add up!
Bear in mind that all of this only happens in the debug environment (so never in production) while you don’t have an editor connected. It’s a rare case, but clearly not so rare that nobody hits it, so we’ll think about putting a message in the logs to give an indication of what’s just happened.
(And for anyone who ever wondered why it took us so long to release an interactive debugger for Anvil…this sort of thing is why!)
3 Likes
Thanks for the detailed explanation.
In my case, I have a background task that generates a PDF. The slowdown happens when the background task executes a deepcopy on the server side, even though the breakpoint is on a client-side module and is not involved at that point.
Each deepcopy slows down from about 0.1 seconds to around 6 seconds, causing the total execution time to grow from about 35 seconds to over 10 minutes.
I wasn’t really able to remove the deepcopy, because it happens inside a library. The code calls two functions from that library: one that only performs a deepcopy, and one that performs a deepcopy plus a lot of unrelated code. In both cases, the execution time increased from 0.1 to about 6 seconds, leading me to conclude that the slowdown is caused by the deepcopy itself.
If I remove the client-side breakpoint or run the app in production, execution completes normally.
Does the behavior you described also explain this, or is this a different issue?
Thanks for the detail! The interactive debugger is a godsent, very happy to live with its compromises and idiosyncrasies.
Thank you !