[Chicago] Status of wsgi
jordanb at hafd.org
Fri Oct 12 05:57:35 CEST 2012
On 10/11/2012 06:35 PM, Tal Liron wrote:
> I think your app is a great use case for Tornado, and a great topic for
> a ChiPy talk. ;)
> But I think it's also pretty clearly not a typical "web" (=REST)
> application. Which is really the myth I'm trying to dispel: if you are
> doing typical "web," async servers are of no particular use to you,
> whether for serving files or serving your own generated HTML entities.
> You yourself are immune to this particular myth, but I think the
> mythical formula "async=scalability" (or, worse, "async=fast") is
> pervasive among those developing typical web applications.
Yeah I know what you mean. I've certainly seen people act like tornado
and twistedweb are scalability-in-a-can. That's partially why I wasn't
ever particularly interested in them until I got a problem that tornado
was able to solve. So I suppose we're passionately agreeing at this point.
To be fair, the whole 'webscale' thing can get applied to just about
anything. I had a client tell me that an investor advised him to switch
from Django to Rails because.. you know.. Rails is scalable.
> I also readily agree that threading is not critical for many use cases:
> running multiple processes can be just fine, as in your case. But this
> assumes that every "worker" is independent and would not benefit from
> collaboration, especially via shared memory states. If you were doing,
> say, video streaming, there would be a lot of benefit in having threads
> coordinate and reuse memory, with a smart load balancer that knows to
> send clients watching the same video stream to the same process. Again,
> Python's abhorrence of threads is often quite perfect and simple. Still,
> it pays to know when it's just not the best tool for the job.
I'd lose my pedantic nerd card if I didn't observe that you can share
memory across processes too, by sharing an mmap.
More information about the Chicago