sophana wrote:
Michael Palmer wrote:
Geoffrey Talvola wrote:
John Dickinson wrote:
Not only that, it consumes a webware thread that could be used for
other requests.
Yes, this won't scale too well if you have large numbers of concurrent
users. You could probably handle hundreds of users with a large
thread pool
though.
According to some measurements I made, a pool with more than 10-20
threads will seriously affect overall performance.
Are you sure of that?
A python thread has nothing in common to standard threads (pthread or
even light weight threads)
It will use some memory, but no performance pelnalty at all.
But there is thread switching going on all the time. The more threads,
the more switching overhead.
I haven't understood why ajax requests require a busy thread to be handled.
Is it because the tcp connection is not closed between the requests?
Why ajax requests are not handled like standard http requests, using a
session Id to maintain the per client state (with a new tcp connection
per request)?
Nevow/Twisted solves this problem by using async event-driven methods
instead of threads. I think Twisted's architecture is a better fit
for this
type of application than Webware's thread pool. I wonder if there is
some
way to combine the two -- use standard Webware threads for "normal"
short-lived requests but have some way to handle the ajax_response-type
requests without tying up threads. It would probably require
reworking the
ThreadedAppServer architecture significantly.
Should work in principle. One problem is the lack of thread priorities
in Python. If you dedicate one thread to the asynchronous requests,
that thread will compete for CPU time against all others in the pool
and may be quite slow. It might be necessary to use several threads to
get more overall CPU time for the async requests.
Why dedicating one thread only? Why aren't the event handled by the same
pool of thread concurrently?
well, in my understanding the proposal was to mix the conventional
threaded execution of 'regular' requests (which allows you to run each
request straight through, without async-specific contortions) with async
handling of ajax requests. One thread cannot at the same time run a
single request straight through and at the same time hop around between
additional async'ed ones. So, you would have to dedicate one or more
threads exclusively to the async'ed handling of ajax requests.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Webware-discuss mailing list
Webware-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/webware-discuss
--
Michael
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Webware-discuss mailing list
Webware-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/webware-discuss