Jim Fulton wrote:

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:


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:


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. :)



Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to