On May 20, 8:48 pm, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> Using mod_perl as an indicator is actually a bad idea. This is because
> it tends to be the worst of the bunch when it comes to bloating out
> Apache. Thus saying that all solutions which embed an interpreter in
> Apache are bad based on what one sees with mod_perl is not a good
> idea.
I'm not using mod_perl as an indicator -- I'm using it as a reference
point and a learning example. Configuring and optimizing mod_perl
taught me the range of bloat and inefficiency in Apache; and taught me
how to best optimize the server. When I HAVE to run apache, I
routinely run multiple versions on each system ( single binary/install
-- different .conf files / ports / startups ) - to better optimize
memory usage and resources. Because Apache is a slower server, tends
to eat a bit of memory on its own - and lots when you turn modules on
-- you can get much better performance by segmenting your
functionality.
> The mod_python module does carry a bit more bloat in its base level
> memory profile than it needs to and this has been identified and
> discussed on mod_python lists, although nothing down about it yet even
> though changes relatively simple to address it.
mod_perl doesn't have bad bloat; I wouldn't say mod_python does
either. but in the perl world, the system acheives massive speed
increases by compiling code into in-memory functions, cloning mem from
the master, and reserving memory as more variables and functions are
called.
a typical child cycle is:
start - 9MB
request 1 - 18MB
request 2 - 24MB
request 3 - 39MB
request 500 - 40MB
then it dies, and we start from scratch
IIRC, you see something similar with mod_php ; by pushing mod_php to
fcgi and using some agressive memory sharing + accelerator caching,
you can make php 4x faster; eliminating apache can make you 10x
faster.
> So, servers like nginx and lighttpd will be better than Apache for
> handling serving of static files. Just because they are though,
> doesn't mean you should also then use them to host your dynamic web
> application code.
That's true.
But they're also better for fastcgi integration, for misc modules, and
many other tasks.
Apache has a ton of documentation, knowledge, and a rich module
library & community. It's a standard, but that's it.
I think this is where we'll have to agree to disagree - you seem very
experienced in Apache and I'm grateful for your insight -- but your
knowledge and understanding of alternative systems is very different.
You've misunderstood the capabilities and focus of servers like Nginx
and Lighttpd , which makes it hard to think of your insight in terms
of comparison.
> With a dynamic application, you can also benefit from doing things
> like turning off keep alive as in general one page will not generate
> successive requests against the Python web application. You would
> still use keep alive on on the static media servers though as that is
> where you would benefit from it.
If you put nginx/lighty/apache on port 80, and proxy to your
webapplication on port 8080 or in a cluster, you can get tremendous
improvements through keepalive tweaking and general request
architecture. you can have your port 80 connection slurp the request,
push it to the app, and slurp the response -- making your appserver
only handle the process time -- instead of waiting for slow clients to
send/receive the request.
> In summary, use each tool for what it is good at. Don't try and make one
> thing do everything.
That's absolutely true.
I think you should really look into nginx and lighttpd -- i think they
might surprise you. They've quickly become the essential components
to all the high-performance wep applications , as servers , proxies,
balancers or gateways -- and for a reason.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
