On Dec 2, 6:09 am, Alvaro Lopez Ortega <[EMAIL PROTECTED]> wrote: > On 01-dic-08, at 19:25, Christopher Grebs wrote: > > > I have read the discussion about the issue of a missing WSGI wrapper > > for Cherokee. > > Please don't call it a "missing wrapper". I'd rather suggest something > like "right technical decision". > > > I'm planning to push my whole infrastructure over to a Cherokee > > based setup. But since there are many wsgi applications running I > > would be pleased to let them run in the same way I did with my > > apache setup. But with all advantages Cherokee provides (Load > > Balancing, easy Administration etc.). I know that WSGI-Based > > applications can run without any code patching on CGI/SCGI/FastCGI > > and so on... But the way WSGI handles just everything is ingenious. > > Well, WSGI is certainly a really interesting thing. It allows > developer to write web applications without having to worry about the > protocol it uses underneath to communicate with the web server. That's > a very good thing, actually. > > So, allow me to clarify things a little bit: The only purpose of WSGI > is to provide an API with which developers could write protocol > independent (as in SCGI, FastCGI, AJP 1.3, etc) applications. > > And here is where Apache'smod_wsgicomes into scene: it basic idea is > to sunk a Python interpreter within the server, so the application > calls go through a intermediate conversion layer to get converted to > something the web server can deal with. > > IMHOmod_wsgiis simply a module that implements many wrong technical > decisions altogether. I wouldn't like to kick off this discussion > again, but basically, linking a whole interpreter within a web server > is a clumsy approach: it's insecure and slow, aside of its flawed > architectural design. > > That is in fact a faster and much more secure and reliable way of > working. _Give it a try, and you will see what I mean_.
If you didn't want to kick off the discussion again, then perhaps hold back on the FUD, especially since it seems you perhaps still don't understand how Apache/mod_wsgi really works. First off, as much as how Cherokee has made specific architectural decisions to achieve its aims, so has mod_wsgi. Just because the Cherokee goals and decisions are different, doesn't mean those for mod_wsgi are wrong. The decisions for mod_wsgi are just as valid because they pertain to the very different execution context of Apache. As to speed, embedding an interpreter certainly does not slow anything down in respect of the WSGI application itself. In theory how mod_wsgi works will actually perform better than FASTCGI/SCGI+FLUP as all the low level flup connection management and data handling code is written in Python, where as in Apache/mod_wsgi it is in C code. Being in C code means that it is quicker, plus the Python GIL is released for greater contiguous sections of functionality whereas in flup, being Python code it is continually acquiring/releasing the Python GIL while it does stuff. You therefore get better concurrent handling in Apache/ mod_wsgi, especially on multi core/processor machines when multithreading in use. Above that lowest level of dispatch, there is going to be no difference as it is all the same Python code executed by the same underlying interpreter. As to performance impact on the rest of the operation of the web server, since Python code only ever gets executed if a URL has to be handed off to a WSGI application, then impact is basically non existent. The only area which would be of concern would be process memory usage because of the persistent nature of WSGI application. For embedded case, such memory usage is going to not be much different to the impacts of running a memory hungry embedded PHP application. Thus in some respect it is an application design choice to run that model. For case of daemon mode of mod_wsgi, neither the execution of Python code or memory usage is an issue as the WSGI application executes in a separate process just like FASTCGI/SCGI solutions. Thus embedding doesn't really come into it at all. All that remains is really the prior issue of Apache's suitability for handling of static files and keep alive issues resulting from using threads over an event driven model. This has got nothing to do with mod_wsgi and mod_wsgi does not make it any worse. So, for static file handling on high performance site, recommendation would be the same. That is, look at offloading static file serving onto a separate server such as nginx, lighttpd or cherokee. Now for security, that also is a specious argument. Using mod_wsgi embedded mode for hosting disparate customer sites would certainly not be a good idea just like using mod_python for the same is not good, but for a self hosted site there would be nothing wrong and it would not reduce the security of your system any more than other common solutions. For shared hosting, or if you want to provide isolation for other reasons such as to allow different applications or parts of them to run as different users, one would simply use mod_wsgi daemon mode whereby you end up with the WSGI application running in distinct daemon processes just like FASTCGI. Latest mod_wsgi code in subversion even supports the concept of chrooting the daemon processes if you want that extra level of isolation. > I do think that your current approach is the way to go: The > application server (your WSGI application) runs in a different process > that communicates with the server through a local (unix?) socket. Just like with mod_wsgi daemon mode. In mod_wsgi daemon mode, Apache is merely acting as a process manager and proxy system, just like FASTCGI/SCGI systems, although some of the latter can't even do the process management. > > Is there any progress on a WSGI module yet? > > Progress? No. It isn't simply on the roadmap. > You can currently run WSGI applications by launching them as > application servers (with either SCGI, FastCGI or HTTP access). Let's > forget about all the hacks Apache had to come up with in order to ease > its performance issues! > > So, summing up: WSGI is a really good thing. However, themod_wsgi's > approach is simply wrong.. and I'm willing to reproduce any of those > Apache's bulky modules in Cherokee. :-) Only wrong in respect of Cherokee. As I have said before, I will agree that Cherokee shouldn't be going off trying to implement an equivalent of mod_wsgi. This is more to do with the architecture of Cherokee not being suitable for doing that sort of thing, not mod_wsgi's approach is wrong. The mod_wsgi approach is quite fine and works well for Apache. Overall these arguments about one method being better than another is such a waste of time, especially in respect of performance. This is because as soon as you load a fat WSGI application your request/sec performance is going to drop so much anyway, that any benefit from one hosting mechanism over another is completely swallowed up, being somewhat less than one percent of overall request time. When one realises this, what is more important is the ease in deployment and management. 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. Graham _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
