[Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)

[Martijn Faassen]

Hey,

Jim Fulton wrote:
[snip]

> I'm not certain that we're actively supporting either server.

But *in practice* we're supporting the Twisted integration, as that's 
the only one that people use now, right? We may not be actually capable 
or willing to offer such support, but since everybody uses it, we do 
support it in practice. Now on to what we would *like* to do...

> Currently, the Zope project has 3 servers, the Zope 2 ZServer,
> the Zope 3 ZServer, which is afaik unrelated to the Zope 2 ZServer,
> and Twisted. (I count Twisted as one of our servers because we've
> put significant effort into integrating Twisted and seem to be
> maintaining the WSGI integration that we're using.)
> 
> I think only Michael Kerrin actively supports Twisted. I'm not sure
> what the status of that is.  The last time I made time to pay attention to
> this, at the time we released Zope 3.2, the Twisted WSGI integration
> had a lot of problems.  I tried to address the most urgent ones, but
> ended up with a server that was much slower than ZServer, which was
> much slower than the Zope 2 server.  I was also alarmed that we were
> maintaining our own Twisted WSGI integration.  I don't know if the Twisted
> community has gotten behind WSGI.  If not, I'm not sure we gained anything
> from using Twisted.

I'm having second thoughts about the Twisted integration for a number of 
reasons:

* Twisted people actively dislike eggs. They won't eggify Twisted any 
time soon.

* Twisted async approach doesn't really match Zope's threaded approach.

and your reason:

* Who is maintaining Twisted's WSGI integration? If that's us, then that 
sucks.

> I'm not sure anyone in the Zope Community has the appetite for performing
> server maintenance.  That is why I was so anxious to move to WSGI.
> Unfortunately, I don't think anyone has gotten very involved with WSGI.

I've only played with it. It's pretty neat:

http://faassen.n--tree.net/blog/view/weblog/2006/11/29/0

The WSGI stuff is getting *lots* of traction within the Python community 
right now.

> When I was raising issues on the Web SIG back around the time of the
> Zope 3.2 release, nobody from the Zope community seemed to be around.
> 
> Here is what I'd like to see.  I'd like to see someone get more involved
> in the WSGI effort.  A very specific thing I think is needed is a WSGI
> server benchmark that can be used to evaluate different WSGI servers for
> both functionality and performance.  This would benefit us and other
> projects.  We should use this to evaluate different WSGI servers
> to see which ones best meet our needs.  This would guide our decision
> whether to continue to try to support any of our existing server
> and might spur server developers to greater efforts and server 
> improvements.

I fully support this idea. This would be great. A commenter in my blog, 
Kevin Smith, had the following to say:

"I've also played around recently with _cpwsgiserver with a full zope3 
instance and casual benchmarking showed about a 20% performance increase 
over zserver and twisted. The casual test didn't account for media files 
or complex pages, but it's very nice to be able to switch out the 
webserver with just a few lines of code. Although very immature FAPWS 
looks promising as a very fast server (uses bindings to libevent) more 
wsgi servers can be found at http://www.wsgi.org/wsgi/Servers"

I've cc-ed him into this, perhaps he's interested. :)

And FAPWS is here:

http://william-os4y.livejournal.com/2616.html

Definitely needs maturing, as Kevin mentioned. If this guy channels his 
energy and WSGI knowledge into twisted.web2 as is discussed in the 
comments, that might also result in the right end-result for us.

> I don't think this is a huge effort and certainly not a technically 
> challenging one.

My blog entry might offer a starting point for those interested into 
looking into this.

> I think that a modest effort that tested some obvious things like
> speed of requests with large and small inputs and outputs, with varying 
> levels of
> concurrency, measuring speed and resource consumption would probably
> spur contributions from others in the Python Web community.
> I would do this myself if I didn't have a number of other projects that
> I'm currently focused on.

I'm not volunteering for this either, but I volunteer to cheerlead this 
effort. :)

Regards,

Martijn