I just tried switching to a simple ajax call and like you said and it's much faster (and there's no unresponsiveness :) ) on pythonanywhere. When I test it locally I see a bit of unresponsiveness but I think that's because pythonanywhere has webworkers while locally there's only a single non-threaded web2py process?
Thanks for all the help Niphlod! Really appreciate it :). On Friday, 3 June 2016 14:18:33 UTC-4, Niphlod wrote: > > an ajax request is just like a user hitting a page. > They get queued until a thread from your web-workers is free (which is > usually ALWAYS the case) and it gets executed right away. > It'll definitely be quicker than the IPC done by the scheduler if you want > semi-realtime execution. > > On Friday, June 3, 2016 at 7:39:44 PM UTC+2, Mark Smith wrote: >> >> Thanks for the response :). I want to explain my situation a bit more if >> that's alright with you Niphlod (I'm a newbie at web dev haha). You're >> right, I think I can use a simple ajax request to do it instead, however I >> think the task may run a bit slower/make the UI a bit unresponsive? From my >> understanding every connection is handled by a single thread so it might be >> the case where a 1-2 second task would take 3-4 seconds to run and in that >> time the server wouldn't be able to handle any further tasks (like updating >> other UI?). Not sure if the previous statements are true however. In my >> case when the user clicks "submit" there's no other UI interaction until >> the server returns back the results of the task so I don't think the UI >> will be any slower (since it'll be an ajax request), but the task might >> actually take longer for the server to run (though anything less than 6 >> seconds would be an improvement :) ). >> >> I'll try implementing it with just an ajax request (and no scheduler) and >> get back with the results. Thanks again for the helpful response! >> On Friday, 3 June 2016 12:45:19 UTC-4, Niphlod wrote: >>> >>> long story short, no. >>> You can get better "pick-up-times" (the time that elapses from when you >>> queue the task to when it's started) with the redis version of the >>> scheduler but in any case the worst possible scenario won't drop under >>> "heartbeat" which is 3 seconds. >>> Got it, would be wonderful if the scheduler was even snappier than it is >>> but.... the current limitation just makes sense for small corner cases, >>> which are: >>> - need to run the task on another server than the web-serving one >>> - need to run zillions of tasks in a hundred workers farm to offload >>> something the webserver can't keep up >>> >>> That being said, there's another, which is "need to run tasks that go >>> beyond the 60 seconds timeout which is enforced in most webservers"... but >>> in that case waiting 6 seconds is not that much in comparison. >>> >>> The thing here is : >>> a) you're using pythonanywhere, so you're out of "worker farms" >>> b) your tasks are super-duper-speedy (they complete well-below the usual >>> timeout for webserver which is 60 seconds) >>> c) you want sub-6 seconds "pick-up time".... >>> >>> why don't you just use a simple ajax request ? >>> >>> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
