Forums

Issues since the maintenance

Hi. When I run the app I have on pythonanywhere on my local machine, each run is super fast (0.000297784805297852 to 0.00347590446472168 seconds). Once I run it on pythonanywhere, the delay explodes (0.855772972106934 to 4.0600757598877, with the occasional 0.484904527664185 seconds). Is it possible that something is off since the maintenance? We have live users on our app, so it's pretty bad that all of a sudden these delays are here.

I cannot really say whether it is exactly since the maintenance today or whether it started last night. I only started clocking now once the delay was there. Who do I contact with this? I only found a feedback form, which is not really useful in this case, is it?

Thanks, Alex.

Hi there -- the feedback form, forum posts, and email to support@pythonanywhere.com are all handled by the same team, so you can post questions/issues wherever you prefer. The only real difference is that the forums are public -- the other two contact points are email-based.

Regarding your app -- is it something you're running from a console? Or is it a website that your users are accessing? Or a scheduled task? What does it do during its processing -- for example, number-crunching, file access, or database access?

Thanks for the quick response. I run the backend for a chatbot on Telegram. I run it through an hourly task, using this: https://help.pythonanywhere.com/pages/LongRunningTasks/ or the console. The task connects our DB to the Telegram API. It polls the bot, retrieves updates and provides the right answers.

It has been working just fine so far. We noticed massive delays starting this morning and, as I said in the original post, when I run the bot on my local machine, it's fast. So I don't think it could be anything else but pythonanywhere, or am I missing something?

Right, it could be a PythonAnywhere thing, at least so long as you're using the same data on PythonAnywhere as you are locally (as, of course, larger datasets can take longer to process than smaller ones). I can't think of anything that might have made it slow down drastically as a result of the system update, though.

What kind of DB are you using? Is it SQLite? That can have pretty poor performance on our systems, because the filesystem is networked rather than locally attached. MySQL or Postgres, which (being server-based) talk directly to their own local storage, are considerably faster.

yeah, I tested with the same data. We currently use SQLite and plan to switch to Postgres soon. Ok. Let's do it like this: I will take this as a reason to switch to Postgres and if the problem persists, I'll reach out to you again. Thanks for the support so far.

Just to be clear though, it was fine yesterday and isn't today. So I think something's off since this morning. Maybe the switch to Postgres will fix it..

Hey Giles, just a quick update. Didn't do anything over night and it is blazingly fast again, even with SQLite. So all seems to be good again. Strange, but at least all problems have disappeared for now.

That's great to hear! And doubly-good news, after some digging, I think I know what the problem was. You're right, it was an issue on our side -- not directly related to the system update, but coincidentally happening at the same time.

It looks like due to a different bit of maintenance that happened yesterday -- which should have been completely invisible to people using the system -- the file server that your account uses had high latency -- that is, if you were reading one large file it would be fine, but lots of small read/writes would have been much slower than they should be. That would explain why I wasn't seeing the problem -- the metrics I was using were all bandwidth-related -- and why other people weren't reporting it -- most filesystem access is bandwidth-bottlenecked -- but does explain why you were seeing it, because SQLite access involves lots of small read/writes so high latency is a serious problem.

Anyway, glad to hear it's all working now. I'd still recommend switching over to MySQL or Postgres anyway, as you'll get much better performance, but at least this removes the urgency :-)

Thanks for the info, Giles. Great you found the issue. I'll do the switch soon. Keep up the good work. Alex.