Need to get more involved in Web SIG (was Re: [Zope3-dev] Fixing ZServer bugs?)
Christian Theune wrote: Hi, I was able to reproduce http://www.zope.org/Collectors/Zope3-dev/714 today. We have a patch from the reporter without and I don't see why the current tests fail to catch this behavior in the first place. Did we ever drop support for ZServer? The changelog reads 'replaced ZServer with twisted' which sounds very much like ZServer was defined obsolete. (And wasn't the goal that we don't have to take care for network servers anymore anyway?) I'm not certain that we're actively supporting either server. 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 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. 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 don't think this is a huge effort and certainly not a technically challenging one. 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. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Need to get more involved in Web SIG (was Re: [Zope3-dev] Fixing ZServer bugs?)
Stephan Richter wrote: On Tuesday 19 December 2006 08:24, Jim Fulton wrote: 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 don't think this is a huge effort and certainly not a technically challenging one. 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 agree with your assessment. It is extremely difficult to figure out which WSGI server fulfills Zope's criteria. In fact, I would suspect that only ZServer (Zope 2 and 3 version) does, because noone else has such strong requirements. What requirements? If we have such requirements, I suggest we reevaluate them. *We do not want to be in the server business!* Perhaps you are thinking of the buffering requirement. I would suggest that this be part of the benchmark. That is, there should be a test of whether someone can DOS a server by connecting with a non-zero content length and then not providing input. I would love to see such a profiling tool too, not only for testing servers, but applications as well. Applications is totally out of scope for this IMO. Everybody wants benchmarks that apply across applications, but that is a pipe dream. OTOH, it should be feasible to come up with a reasonable set of tests that can be used to compare servers. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Need to get more involved in Web SIG (was Re: [Zope3-dev] Fixing ZServer bugs?)
Anyone played with Nuxeo's 'funkload'? That's probably one of the most interesting stress/benchmark tools out there. There are other non-Python options too, like 'JMeter' (I believe that's the name) and Microsoft Web Capacity Analisys Tool (free download I believe). -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
