On Mar 26, 11:00 am, Damjan <[EMAIL PROTECTED]> wrote: > >> I'm looking for beta testers for a high performance, event-driven Python > >> application server I've developed. > > >> About the server: the front end and other speed-critical parts of the > >> server are written in portable, multithreaded C++. > ... > > Why not just put it on the net somewhere and tell us where it is? > > People aren't generally going to want to help or even look at it if > > you treat it like a proprietary application. So, put the documentation > > and code up somewhere for all to see. > > BTW, multiprocess web servers such as Apache can quite happily make > > use of multiple cores. Even within a single Apache multithread process > > it can still use multiple cores quite happily because all the > > underlying network code and static file handling code is in C and not > > subject to the GIL. So, as much as people like to bash up on the GIL, > > within Apache it is not necessarily as big a deal as people make out. > > BTW nginx now has a mod_wsgi too, if someone is looking for an Apache > replacement.
Yes that is a viable option, as still are existing fastcgi solutions for Apache, lighttpd and nginx. Because the bottlenecks are generally going to be in upper application layers it really comes down to personal preferences as to which you want to use, which you find easier to configure and manage, plus which you trust as being the most secure and stable. For truly high demand sites you should also be looking at spreading load across multiple hosts, not just because of performance but also because of redundancy. You would also be serving media off a different web server to your Python web application and configuring each web server to the specific task it is doing. So, there is a lot more to in than raw speed of underlying technology and so one should always treat with caution something that is being sold as some better way of doing things. This applies to Apache mod_wsgi, nginx mod_wsgi or anything else for that matter. All have benefits, but they also have shortcomings in different areas which may not always make them suitable for all applications, or at least they may need to be configured in specific ways to make them perform best for specific applications. Anyway, because it isn't that simple is why I'd like to see some actual documentation for this new contender posted in a public place, along with code being browsable so one can evaluate it without having to sign up for some closed beta program. Graham -- http://mail.python.org/mailman/listinfo/python-list