Forums

Hi, thanks for the great product my site is up and running.

I have a couple questions about web workers.

My site is a personal webpage that is important for my current job search: I don't expect many users but it does have some heavy-lifting code on a couple of the sub-pages (machine learning, 3rd party scraping, etc.).

I tried to deploy it with just 2 web workers and I crashed it by checking it through my laptop, mobilephone, and my friend's computer (only 3 people with password access). More specifically, I could run the heavy sub-pages once but then I would get a Server Error (500). I then had to reload the app from python anywhere and I could start the loop again (run the heavy code once, then server errors). My first question: Can you explain the nature of this error? I'm not surprised it's there I would just like to understand why the app works at all. I'm a bit of a noobie to web deployment.

Also, can you recommend a way to select the proper number of web workers? Last night, I increased it to 10 and it definitely works better. Is there an easy way I can monitor for server error and adjust the web workers accordingly? Is there a more sophisticated way to design this besides trial and error?

So if your heavy lifting code takes say 1min to run, then as you start visiting the page and running that code, the first request ties up your first web worker for 1min, then the second web request ties up the second web worker for 1min, and so the third request would have to wait for one of the workers to finish processing before going on to process it.

If you access it 11 times quickly, then for the 11th hit, that may take say 5min waiting + 1min processing = 6min before you get a response. So selecting the # of web workers is based on what you think peak traffic may be (eg: per minute), and what type of response times you think is acceptable, then using the thought process outlined above to figure out the # of web workers you need.

Another thing to look out for is if your processing time takes >5min. Http protocol for web requests is very bad at dealing with these long processing times, so anything taking more than 5min to process is automatically killed on our end. The correct thing to do (from a code design standpoint) would be to offload everything say to a scheduled task, so none of your web workers are tied up.

However, if you run the heavy lifting code once and then it just breaks forever (instead of freeing up after a minute), then something is wrong with your code.

Ok great, that helps.

For more info. The biggest page takes ~1 min to run on my local computer (which is nothing special). The next biggest takes about 15s, the rest are <1s. So I shouldn't get any requests longer than 5 min if it's setup properly.

I'll stick with 10 workers for now and adjust accordingly. Unless a lot of potential employers are running my app I should be fine. If more than that are checking it out at once, I'll have more important decisions to consider!

Sounds like a good way to go! So long as no more than nine people hit the big page within a minute or so of each other (which would leave nine of your workers busy, and one spare to handle the more lightweight pages) then as you say, you'll be fine. BTW one extra thing that might be useful is the access log for the site; each page hit has a response-time at the end, so you can see how long each view is taking on PythonAnywhere as opposed to how long it takes on your own machine.

Is it possible to add more than 69 web workers to my App?

yup, just let us know and we will temporarily bump up that limit for you to upgrade/change your plan.

What if I have Billions of Users logging at the same time. How many Web Workers should I need. Like Facebook?

That depends very much on your code. If your views take longer to respond, you need more workers and if you get more hits on your site, you need more workers. For instance, if you have 2 workers and your views reliably respond in 0.1 seconds, you can handle 20 hits per second, but if your views respond in 0.5 seconds, then you can only handle 4 hits per second.

Ok Thanks.

Awesome guide for newbies. I got additional question When you say response time you mean backend response time correct? ie. response time doesn't include the frontend loading time.

Response time is the time of producing respose for the request. Rendering of frontend in the browser is not covered by that.

Thank you, makes sense