Beta testers needed for a high performance Python application server

[Graham Dumpleton]

On Mar 26, 11:00 am, Damjan <gdam... at gmail.com> 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