Debugging web2py apps

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugging web2py apps

WingIDE - User mailing list
When debugging my web2py (web-application framework that uses Rocket for
http server) and my front-end fires off multiple ajax requests after
page load the requests are seeing really long (7 - 8 seconds) TTFB
waits. If I run the server outside of Wing the requests are serviced in
sub-second times. So I'm thinking is something to do with thread
management (I believe the http server creates new worker threads for
each request but not really sure)?
Is there a project setting in Wing I could try that would allow multiple
requests to be served concurrently or am I barking up the wrong tree?

Thanks,
Max
_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide
Reply | Threaded
Open this post in threaded view
|

Re: Debugging web2py apps

WingIDE - User mailing list
Max Slimmer III via wingide-users wrote:

> When debugging my web2py (web-application framework that uses Rocket
> for http server) and my front-end fires off multiple ajax requests
> after page load the requests are seeing really long (7 - 8 seconds)
> TTFB waits. If I run the server outside of Wing the requests are
> serviced in sub-second times. So I'm thinking is something to do with
> thread management (I believe the http server creates new worker
> threads for each request but not really sure)?
> Is there a project setting in Wing I could try that would allow
> multiple requests to be served concurrently or am I barking up the
> wrong tree?

Do you know if it's threaded or using a process pool?  If threaded, it
may matter that Wing's default is to stop all threads when a single
thread stops.  You can identify only specific threads to debug (so other
threads are left to run) but to do this you need to start debug using
wingdbstub.py.  I can send details on that if this is even relevant.  It
shouldn't be if you're not actually stopping at breakpoints or
exceptions during the times where it's slow.

If it's using multiple processes it's possible that the Debug Child
Processes setting in the Debug/Execute tab of Project Properties will
help.  If that's on, maybe there is overhead from attaching many
processes.  However, this is off by default so it may not be it either.

You should be able to identify whether it's threads or processes by
stopping at a breakpoint or exception and looking at the process /
thread / stack frame selectors in Stack Data, Debug Probe, and other
debugger tools.  If there is only one thread the thread selector is
omitted.  I think the process selector is always visible if
multi-process debugging is on (which it is by default; it's only
automatically debugging child processes that's off by default).

All that said, it could be something else as well.  I would probably try
running in a profiler to see where the time is spent.

--

Stephan Deibel
Wingware | Python IDE

The Intelligent Development Environment for Python Programmers

wingware.com


_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide