Forums

Well, earlier today, PythonAnywhere was unreachable for me and for the LSL scripts of mine that connect with my app.

What I'm doing is using Python Anywhere as a transient cache for URL data. The LSL language (Linden Scripting Language) is for objects in Second Life, InWorldz, OpenSimulator, and similar systems. Each script can obtain a URL, though the URL is ultimately transient (it will eventually expire, such as if a simulator or the script restarts). So, I am using PythonAnywhere to act as an external cache for the URL's, so that my objects can communicate with each other.

Even after connectivity was re-established, however, it was nearly two hours before my LSL scripts were able to re-establish contact with my python application. It wasn't until I manually shut down every single script and then restarted them one-by-one that normal functionality was restored.

From what I can tell, this may be a flaw in the Flask framework, which in my experience tends to choke whenever it gets hit by multiple requests simultaneously.

Does anyone know of a solution that I can use? Is threading an option?

I see that the "choking on multiple requests" issue is resolved by deploying a flask app via WSGI or other such systems. Problem though, is that I think Python Anywhere is already doing that by default, so either it's not solving the problem or the problem lies elsewhere.

Hi zauberparacelsus,

Free accounts have only one uWSGI worker. So yeah, if generating a response takes 4 seconds. Then you would only be able to deal with a request every 4 seconds. If you were getting more than 4 requests a second then they would start queuing up. Paid accounts have more uWSGI workers. Of course taking a long time per request is not optimal anyway. So it depends on how you have written your code. There is nothing stopping one worker from dealing with hunders to thousands of requests per second. But if you have the equivalent of a time.sleep(10) in your code then it will only handle exactly 6 requests a minute :-)

Well, the requests are usually instantaneous (or nearly so) for me. The most load-intensive things they do is crunching SHA-256 hashes and making SQLite requests.

Now though, how many uWSGI workers does each account tier have? I don't see that listed for the account features.

Hosting accounts have 3 workers, currently. Are you sure you have the right diagnosis though? If requests are usually instantaneous, but your LSL scripts took almost two hours to connect... How many are there? Have you taken a look in your access log file, to see how many requests you're getting per hour?

Yeah, it was overloading. The primary problem was that my timeouts were too short, so the requests just started piling up. So, what I've done is increased the timeout lengths to make my LSL scripts less "impatient", and I've improved the code to minimize how much the scripts rely upon my app. That, and I've improved their error handling.

It's been 3 days without any further problems, so I'll see how well these changes go.

Well, 11 of the LSL scripts suddenly hit the python app simultaneously, and it had no trouble at all handling them, so my previous conclusion of there being too many requests at once was in fact wrong.

So, the problem was most likely with requests taking too long to get through to the server.