I’m running a discord bot on replit, and lately I’ve noticed a big lag when executing commands in the discord…
It used to take at worst about 500ms to complete, but recently this got very laggy, doesn’t go under 4000ms… I thought it was due to my console output usage, so I removed it but that hardly made a difference.
Also, noticed that calls to replit.db are also lagging (used to take about 45-70ms to read from replit.db, now it’s 200ms average) but not enough to cause 4000+ ms lags in total (I’m not making that many requests to replit.db to add up).
Anyone else noticing similar issues after the new console feature?
Thx @NateDhaliwal, yes, but I think internet connection is not an issue here, the bot code is hosted on a replit, I’ve used “time.time()” function to measure the execution time of functions…
Just yesterday I was getting less than 500 ms (as expected), but recently it just spiked up to above 4000 ms and I can’t see why, the only thing that changed in the meantime is the new console feature.
I tried restarting the replit and running it again, but didn’t help.
I’m running this in development server, boosted, always on, but seems performance took a hit after the new feature. Not sure if it’s the cause or correlation.
I’m still having a pretty bad performance compared to how it worked before… I’m using a 4x boost on that repl (2v CPUs) but it’s performance is closer to sub-free tier currently (like about 0.25v CPUs) compared to performance from 2-3 days ago.
Would you mind sending me the link to your Repl? Also, if possible, could you record a loom.com video of the issue and share it here so I can see exactly what you’re seeing?
Does anything change when you run kill 1 in Shell to reboot? If you can’t do that, fork the repl for the same effect. If it does it could be a second wave of this.
Tried kill 1 in shell, restarted but no improvement in performance…
The problem is not compiling… I expect there to be some delay in starting the bot (repl) and communication between discord and bot (repl), but the “process time” I’m measuring was just on the server side while executing a function, the biggest bottleneck used to be repl.db but now it just runs at 10% of what it used to, like vCPU is very under-performing, resulting in the 5000+ ms process time average.
Would you mind adding a print to the console right before you send a response to the request in the server to ensure that it’s not the outgoing message that takes a while? I’m wondering if the Repl itself is slow or if delivering the message is (Discord’s end).
Ok, added a few prints, should be visible in the loom video
Here’s the console output also, the timer starts when the function is called (after being triggered by discord command) and ends just before sending a message to discord.
These used to be about 500 ms at worst, but just after the console update the performance dropped drastically, the code remained the same (except some prints) from before and after the performance drop.
Awesome, thanks for this! Could you try one last thing for me before I send this off to the engineering team? Could you copy your code into a new Repl manually (don’t fork the Repl, I want to ensure it’s created from scratch) and see if that improves the performance?
I’ve seen there was an issue with creating a new repl, but it’s working now.
I’ve recreated the function in a fresh repl and it’s working perfectly.
On a fresh repl, the same function takes less than 1 ms and most of the previous 500 ms was due to repl.db calls.
What is your suggestion now? Should I open a fresh repl and re-create my bot there? But since I’m using repl.db, that might not be that simple for me… I’ll have to migrate somehow all that first.
Anyway, thanks for your help I’ll try to migrate everything and if I encounter a same issue, I’ll let you know.
so the problem may re-occur when your db fills up. Ensure that you’re using AsyncDatabase instead of replit.db and if possible, keep values cached in a dictionary to prevent repeated requests.
Yeah, it was causing some delay (not the 5000+ ms), but it was ok… but I’m planing to change how to store data… was doing some testing with file storing and seems to be quite efficient.
Before, one call on the replit.db would cost about 50-70 ms to read an entry.
Saving from memory to a file the same amount of data costs 3-4 ms… I know, totally counter-intuitive.
And reading from a file and having it stored in memory costs less than 1 ms effectively.
A bit more parsing the data is required, but still it’s way better compared to deplit.db in my case
I’ll try to migrate everything and if I encounter a same issue, I’ll let you know.