On Jan 15, 12:36 am, Tycon <adie...@gmail.com> wrote:
> I specifically meant modwsgi's daemon mode is a hack, which is like I
> explained a proprietary
The wire protocol used is actually only a slight variation on the wire
protocol used by SCGI. The differences are that there is an initial
handshaking to determine if daemon process feels it needs to restart
before handling the request, and that header length information is as
binary byte values rather than ascii, so that it can be decoded more
efficiently.
As mentioned by someone else the wire protocol is irrelevant as what
is important is the WSGI API calling interface. As such daemon mode
should be seen as a black box, the internals of which you shouldn't
need to care about.
> unreliable
I have not seen you report any bugs to the mod_wsgi list or issue
tracker detailing how it is failing and neither has anyone else for
that matter.
The only known issue with the way daemon mode communication works is a
blocking problem with large posts greater than system UNIX socket
buffer size when content not consumed by application and it then in
turn sends a response greater than UNIX socket buffer size. This
problem also affects mod_scgi, mod_cgi, mod_cgid and theoretically in
some configurations mod_proxy (from reading source code). In case of
mod_proxy it probably is hard to trigger as it is using INET sockets
and not UNIX sockets.
Only platform this issue really affects is those with very small
default UNIX socket buffer size like MacOSX. To cope with this there
are configuration options in mod_wsgi to increase the buffer sizes.
There are also socket timeouts to detect the situation and recover
from it automatically. In practice, no one has been reporting the
problem in real installations.
> and non scalable communication
> protocol.
As I explained previously and which you are ignoring, horizontal
scaling is performed exactly like you would with any web server. You
stick a proxy/load balancer in front and spread everything across
multiple machines in a cluster.
There is actually specific code in mod_wsgi to deal with this
situation for case where each machine only has a single daemon
process, but many processes across a cluster. The feature is a way of
ensuring that wsgi.multiprocess flag is set correctly to True rather
than False as would be case when only one machine on a process. For
other WSGI hosting mechanisms have seen, not sure they have a way of
overriding this and so each machine thinks it has the only process,
which is wrong. If applications rely on wsgi.multiprocess they could
then behave incorrectly. Only answer in that case is to hack a WGSI
middleware into stack that overrides it.
BTW, technically FASTCGI is not faster. This is because with FASTCGI
you have to use flup code. Being Python code that slows things down
much more than the pure C code in the mod_wsgi daemon process doing
the same thing.
> As for embedded mode, it's not a hack but as it turns out its
> performance isn't all that great given that it under-performs a pure
> python HTTP server like the one in CherryPy.
Which is still debatable, plus have already pointed out, the
differences get swallowed up as noise in overall request time as this
isn't where your bottleneck is going to be.
As I pointed out right at the beginning. Even when you try and correct
the misinformation that people put out, they still don't change their
tune. As such, this is all the time I am going to waste on this.
I will though do again my own benchmarking. Maybe CherryPy WSGI server
has improved since last time I looked. Either way I am not going to be
too concerned as I am not out to make Apache/mod_wsgi the fastest
thing in the world, nor am I expecting everyone to use it. I work on
it purely because I find it an interesting thing to work on. So, as I
always say, use whatever you feel like using, but if you are going to
try and discredit other options, please back it up with real evidence
in the way of actual benchmark data and configuration information,
which you still haven't done so.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
