On Dec 2, 4:31 pm, "Michael Schurter" <[EMAIL PROTECTED]> wrote: > On Mon, Dec 1, 2008 at 5:33 PM, Stefan de Konink <[EMAIL PROTECTED]> wrote: > > > Graham Dumpleton wrote: > >> One also has to realise that no one single web server is going to be > >> the answer to everything. Apache/mod_wsgi can be a really good > >> solution for hosting dynamic Python web applications, but as I said > >> before, for serious sites you may want to use a different web server > >> for serving static content and large media files. > > > What about the put mouth money thing. It is not difficult to write a > > handler. How difficult would it be for someone that really really likes > > mod_wsgi to put on a bounty or start coding? > > > Maybe do it as information source, etc. > > > So much debate, so few work. > > Put your money where your mouth is? Graham has never suggested > Cherokee should have a mod_wsgi work-a-like, so I'm not sure what > you're asking him to implement. Its as if you aren't reading Graham's > excellent responses. > > As a current Apache+mod_wsgi user looking forward to someday migrating > to Cherokee, its discussions like this that make me question my desire > to move. Graham has done nothing but explain how Apache+mod_wsgi > works, and how Cherokee works differently. Unlike the Cherokee > community, he has never resorted to subjective statements about which > platform is "best." > > What might be useful is if someone wrote a FastCGI->WSGI > implementation in C (meaning Python would be builtin). This would be > as close to mod_wsgi as you'd probably want to get with Cherokee.
I would concur that for the speed freaks, or those who like to prematurely optimise, this would be a more reasonable approach. Just remember my warning though that once you load up a large WSGI application, any reduction in underlying layers handling requests will not be that noticeable. This is because the bottleneck will be the applications Python code or database queries. So, possibly also just a waste of time. That said, I have myself looked at C extension module for Python that would talk the Apache/mod_wsgi socket wire protocol so as to allow alternate variant of mod_wsgi daemon mode. The intent here would be to allow daemon to be a proper fork/exec of distinct 'python' executable. The reason for this would be to allow use of different installations/ versions of Python. Thus Apache/mod_wsgi would be able to cover embedded, forked daemon (current daemon mode), or a forked/execed daemon mode (like true fastcgi). Adding this is in no way an indication that it is a better model, but is a recognition that different people require different types of setups. One setup will not provide all features or performance characteristics that people want. You may gain something from doing it one way, but you can also loose out on other things. Best one can hope for is to just make it all as simple to setup and use as possible. > The only way to get closer without doing the dreaded > embedding-an-interpreter-in-your-HTTP-server is to create a special > handler specifically designed for efficient communication to this > mythical WSGI C implementation. The communication could be TCP/IP, > UNIX domain sockets, shared memory, or any other RPC mechanism you > want to dream up. Hmmm, you mean like FASTCGI/SCGI. This is after all what they are for. :-) For Apache/mod_wsgi embedded mode, there obviously is no socket involved, but for daemon mode where there is a UNIX socket used to communicate to daemon process, the wire protocol isn't really that much different to SCGI in purpose. Differences are that since it knows it will be on same box it sends things like lengths in request down as binary rather than having to encode/decode to neutral ASCII string representation. The response is just a normal HTTP type response like with any CGI, as is the case also with SCGI. Apache/mod_wsgi also performs a little handshake of sorts to determine whether daemon process has detected that it needs to perform a restart before handling request, due to WSGI script file having been changed since last request. In the future Apache/mod_wsgi will actually move to a packet oriented protocol in both directions across the socket connection similar to FASTCGI/AJP. This is so that it can implement end to end 100-continue functionality. AFAIK, neither the FASTCGI or AJP protocols support the concept of end to end 100-continue processing, so can't use them. They also don't support the higher level handshake related to application restarts. > When people ask about mod_wsgi, lets reply with 2 simple factual > statements that make no value judgments: > > * WSGI is a Python API. mod_wsgi connects this API with Apache's > either via embedding or UNIX domain sockets. > * Cherokee only supports language agnostic protocols such as CGI, > FastCGI, and SCGI. There is no plan to add a Python/WSGI specific > handler at this time. > > Thanks to both the Cherokee developers and Graham Dumpleton for making > projects I use and love everyday. I hope both projects can benefit > from the others existence. :-) Yes. In the past I have found it rather disappointing (and sometimes funny) how the developers who work on the cores of Apache, nginx and lighttpd always seem to be making disparaging remarks against each others products and the benchmarks they each produce. Seems that Cherokee is going this path as well. As you say, when will people just learn to get along and rather than criticising other products, learn from each other and recognise that perhaps the products fulfil different needs. In the Python/WSGI world I have also seen the same sort of problem whereby people regard Apache as evil and as such totally ignore what Apache has done before. Thus rather than producing WSGI middleware or applications that are friendly to things like Apache authentication and authorisation mechanisms, they go off an implement there own totally independent systems which more often than not do not work nicely together when you do want to use Apache to do this sort of stuff. In Apache 2.3/2.4 there will be a new mod_session module for handling single sign in across applications written in different systems/ languages. I really hope that when this comes along they don't ignore it just like everything else Apache has, as SSO across Python web applications is currently a really poorly supported area. Also, in respect of future Apache changes, in may be of interest to know that there will also be a new MPM which tries to better deal with issues such as keep alives holding up threads, by handling all such held over connections in one thread. Along with this there is also work to collapse the concept of prefork/worker into the one MPM as well, with number of processes/threads all being configurable more easily and avoid needing to even choose between prefork or worker as one MPM will be able to do all efficiently. Graham _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
