I fell for that one darned library that tries to access a sqlite db synchronously, and now my project is constantly freezing up.
We’re talking like ~15 second latencies though. That’s abnormal.
I fell for that one darned library that tries to access a sqlite db synchronously, and now my project is constantly freezing up.
We’re talking like ~15 second latencies though. That’s abnormal.
Well, use rewind, it should inside, or next to tools. Go to before you installed it and you should be good.
I made a monitoring page for this: https://trusted-seemly-ceres.glitch.me/
You’ll see boxes representing the latency over time. Most recent measurements are on top. Occasionally the latencies are extremely high, so it’s plotted on a log scale.
This tests the latency on the projects drive with this command:
dd if=/dev/urandom of=.data/scratch.dat bs=32 count=1 oflag=sync
This makes a small write and waits for it to complete. The monitor runs this periodically and times how long this operation takes.
I’m not running this as an always-on project. I only run it when I’m using Glitch. Different runs are separated by the word “gap.”
@glitch_support, could you please add a projects disk latency monitor to status.glitch.com
Very weird through, anyway did you try rewinding your project?
Nah. The author of that synchronous library actually makes some compelling points about how it’s really fighting an uphill battle to try to make concurrent async requests to sqlite. Although I do wonder if there could be an async but still serialized library, where there’s a single worker thread doing the sqlite work.
Plus, even if I did rewrite the project to save data asynchronously (incidentally I can’t actually rewind to a different version, because already migrated the user data), it would still be too worrying to leave these writes up in the air for >5 minutes. The latency is literally high enough that Glitch could put the project to sleep while we’re waiting for a write to come back. My app will have no idea if stuff is being saved or not. Right now I think it’s better to be transparent in this way and make it very evident that the app is on fire, and their stuff is not being saved.
Maybe there is a issue at glitch’s end. Or something is very wrong.
Maybe use an other library ?
It’s okay, the monitoring is done without that library in question. It’s meant to be a metric independent of library choice.
dd: error writing '.data/scratch.dat': Input/output error
oh no, now it fails outright sometimes