On Jan 14, 10:42 am, "Mike Orr" <sluggos...@gmail.com> wrote:
> On Tue, Jan 13, 2009 at 6:52 AM, Tycon <adie...@gmail.com> wrote:
> > Last word on modwsgi and its "daemon" mode, which is similar to
> > reverse proxy and fcgi in that it separates the web server and app
> > server. As such, it has the same theoretical performance as reverse
> > proxy and fcgi (which in fact provide the same performance), but it
> > uses a proprietary communication protocol, and inlike proxy or fcgi,
> > it requires the app and web server processes to be on the same machine
>
> Is *that* what you're talking about when you say "daemon mode" and
> "proprietary protocol". I thought you meant daemon mode as in running
> PasteHTTPServer or CherryPy as a daemon, and proprietary protocol as
> in WSGI or SCGI.
>
> The main point of mod_wsgi's daemon mode is to isolate bugs/memory
> leaks between the web application and the server, and to track the
> application's individual resource usage in the 'ps' listing. It's not
> designed for multi-machine scalability.
>
> As for its "proprietary" protocol, I consider that an internal matter
> of mod_wsgi. What matters is whether it works, and I haven't heard
> any complaints in that regard.
>
> Ultimately it comes down to the sysadmin's time of setting up mod_wsgi
> now and possibly switching to something else later, vs setting up
> something multi-machine scalable now (which is more work up front).
> And that depends on how likely a traffic onslaught is, how quickly the
> load will accelerate, and the sysadmin's future availability.
You don't need to switch to something else when you want to go to a
multi machine configuration. This is just part of the FUD that they
were pushing on the irc channels in the past to try and discredit
Apache/mod_wsgi. It just seems that Tycon is parroting this same
message. I wouldn't be surprised if he has never even used Apache/
mod_wsgi. Certainly the originator of a lot of this FUD on the irc
channels in the past freely admitted he had installed neither
mod_python or mod_wsgi with Apache.
When you want to start looking at horizontal scaling you do exactly
what you would do were you scaling up Apache for any other scenario.
That is, you stick perbal, pound, nginx or some other proxying/load
balancing solution in front and run an Apache instance of each of the
machines in your cluster.
Since running nginx in front of Apache/mod_wsgi to handle static files
is a common scenario, that same nginx instance could be used for the
job, given that it still likely going to handle the load of both
static files and proxying fine because of being event driven rather
than threaded.
Hmmm, this sounds exactly like what is because suggested if using
paste server or cherrypy wsgi server. Strange that.
When you read this persons other posts I think it is quite clear that
he doesn't really understand the difference between the WSGI
specification and mod_wsgi as an implementation of it. Specifically
that WSGI is a programmatic API and not a wire protocol. It is also
questionable how much he knows how to setup Apache and mod_wsgi.
Probably will never see anything about how they actually configured
Apache and mod_wsgi for these benchmarks that he surely must have run
to come to these conclusions. Like most benchmarks they are probably
flawed due to not setting up his tests properly so equal comparison
was being performed, or not even benchmarking something realistic.
What I find particularly clueless about comparisons between different
hosting mechanisms for dynamic web applications is that they quite
often test a hello world application and not a real application. As
such any figures are pretty meaningless given that any difference
between different hosting mechanism is likely in milliseconds. When
for a large application the overall request time is in the 10-100
milliseconds, the difference just disappears as noise within the real
bottleneck which is the application and or database access. Add on top
of that that you would never want to run your web server at maximum
capacity on an ongoing basis, you would generally have more than
enough headroom even if different hosting solutions perform a bit
different, thus differences don't matter anyway.
Overall one would be much better off focusing your time on improving
the performance of your application and database access than having a
pissing contest about raw request throughput for some unrealistic
pattern of traffic that your site will never experience.
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
-~----------~----~----~----~------~----~------~--~---
