Mark Foster wrote:
> 
> Excerpt from the mod_perl performance tuning guide:
> "The primary way to achieve maximal performance is to reduce the resources
> consumed by the mod_perl enabled HTTPD processes."

This optimizes the HTTPd process, and is certainly the first step -
however, if your actual application design has other
limitation/restrictions, this has little to no effect.

> Certainly they are only part of the system. Being that, they are also
> a(nother) potential bottleneck in the number of users that can access a
> website at once.

I'm quickly coming to a determination (correct or otherwise) that your
application design actually does very little in the way of database
access, remote datasorce polling, or computational tasks.

Rarely have I seen a serious web application benefit from more HTTPd
processes on the same machine.  It is far more typical to "load balance"
across multiple machines as resources are then spread across multiple
machines.  This also lends a hand to creating fault tolerance.  There is
definitely a minimum number of processes needed to be present to fully
utilize the machine, but additional processes past that amount don't do
anything but consume resources.

> No problem. I've found some great information at the following links, in
> case you haven't seen them:
> http://perl.apache.org/guide/
> http://perl.apache.org/tuning/
> I've also found the book "Web Performance Tuning" (O'Reilly) to be helpful.

See my first comment.
and .. be careful .. you're starting to put a Perl vs. Java slant on a
language-neutral discussion.  My points are irrespective of the choice
to use Jserv or mod_perl .. they're universal constants of good
application design and engineering.

..kindest regards,
-dsp


--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
READ THE FAQ!!!!     <http://java.apache.org/faq/>
Archives and Other:  <http://java.apache.org/main/mail.html/>
Problems?:           [EMAIL PROTECTED]

Reply via email to