[Twisted-Python] WSGI Thread-management strategy

Jim Fulton jim at zope.com
Thu Dec 15 16:22:21 EST 2005


The strategy used by twisted WSGI, as I understand it, doesn't meet
our needs. Currently, a thread is created for each request.  The total
number of threads is throttled, I gather using a general Twisted
thread limit.  WSGI applications are called as soon as input headers
have been received completely. An application may be called before all
body input is received.  We need application calls to be delayed until
all request input has been received,

In an application like Zope, application threads are expensive.  There
are application resources, such as database connections and caches
needed by the application threads.  To limit resource consumption, we
have to limit the number of application threads.  Because the number
of threads is limited, application threads are scarce and thus
valuable resources that need to be used very efficiently.  In
particular, we don't want to tie up an application thread waiting for
request body input.

I propose that the default thread-management strategy should be to delay
calling an application until all request input has been received. If
this isn't the default, then there should at least be an option to get
this behavior.  (Of course, the buffering strategy needs to be clever
enough to switch to a file when the input gets over some size.)

Thoughts?

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org




More information about the Twisted-Python mailing list