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.
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?
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