Can we get more clarity about how autoscale works. I tested out hosting a simple one worker flask site on it, and after 15 minutes of inactivity any new request endures an excruciating 20-30s boot and then response. Without any further details on what to expect, I can’t tell if this is a bug or a feature.
1 Like
I’m quite sure the every 15 minute boot is not a feature of autoscale deployments, after all, deployments are supposed to stay on.
3 Likes
It’s closer to 15 seconds, but still unacceptable for an end user. I assumed I was just using it for the wrong thing, guess it’s time to make a proper bug report.
2 Likes
Hey Harrison! 15 seconds definitely sounds too long for it to start, we’d be happy to help figure out what’s going on. If you have the time, could you set up a meeting with us here?
4 Likes
Thanks for the response. Those timings will be difficult for me right now (midnight in Bulgaria), so lets check first it’s not something obvious.
I’ve got a fairly simple flask app, running on the dev server. I know it’s not ideal, but with no accounts, no payments, sanitised inputs it’s not been a priority. No performance issues at all, generally runs lightning fast.
However, after inactivity the response first response is extremely slow. The logs tend to look something like this. Pay attention to the ‘starting up application’ line. As far as I can tell, this only occurs after 15 minutes of zero requests:
09/13/23 08:29:03 PM
127.0.0.1 - - [13/Sep/2023 17:29:03] "GET /result-page HTTP/1.1" 200 -
09/13/23 08:29:03 PM
127.0.0.1 - - [13/Sep/2023 17:29:03] "GET /result HTTP/1.1" 200 -
09/13/23 08:29:02 PM
127.0.0.1 - - [13/Sep/2023 17:29:02] "e[35me[1mPOST /process HTTP/1.1e[0m" 202 -
09/13/23 08:28:37 PM
127.0.0.1 - - [13/Sep/2023 17:28:37] "GET / HTTP/1.1" 200 -
09/13/23 08:28:32 PM
e[31me[1mWARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.e[0m
09/13/23 08:28:32 PM
* Running on all addresses (0.0.0.0)
09/13/23 08:28:32 PM
* Running on http://127.0.0.1:81
09/13/23 08:28:32 PM
* Running on http://[hidden]
09/13/23 08:28:32 PM
e[33mPress CTRL+C to quite[0m
09/13/23 08:28:32 PM
* Serving Flask app 'main'
09/13/23 08:28:32 PM
* Debug mode: off
09/13/23 08:28:32 PM
forwarding local port 81 to external port 1104
09/13/23 08:28:24 PM
starting up user application
09/13/23 08:11:39 PM
127.0.0.1 - - [13/Sep/2023 17:11:39] "e[33mGET /static/favicon.ico HTTP/1.1e[0m" 404 -
3 Likes
Let me know if there’s any other information I can share, it’s a private repo so can’t post it on the forum.
2 Likes
Same for me : if the deployed Repl (autoscale) is not used during a specific period of time (quite short), it will completely stop. And when it comes back on the next call, it is quite slow to start it again. And everything is resetted just like on the first deployment.
I think it’s the feature of Autoscale : if you want a real always on server, you need to do the deployment on a Reserved VM. Unfortunately the Autoscale likes to go to sleep quickly…
2 Likes
I wish Replit were more transparent about what performance we should expect. Does no activity mean a cold start, or is there something more clever going on with hibernation?
There will occasionally be “cold starts” but they should not be nearly this long. We’re in the process of figuring out what causes this for some folks.
It’s a bit hard for me to figure out what’s going on by your logs, but it does look like it encountered a cold start. We’re also working with our support team to improve our documentation on Autoscale, should be updated soon!
2 Likes
Is there anything I can provide that would help the team. Otherwise I will see if I have a free evening next week for a call?
I am having the same issue with a python flask app. Repl is lightening fast. Autoscale deployment is lot slower than running on repl. The repl is on 2vCPUS with 2GB RAM while autoscale is at 8vCPU / 32GB RAM.
Even without the cold start problem, repl instance is a lot faster than the autoscale deployed instance. What am I missing?
1 Like