httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasmus Lerdorf <>
Subject Re: PHP UserDir MySQL Security Puzzle
Date Sat, 22 Jun 2002 01:34:36 GMT
Well, you'd want more than one process per instance.  20 instances vs. 20
processes really isn't very different if each instance is just 1 process.
Where the additional load comes is through the fact that each instance
should probably have at least 5 processes.  You can do a StartServers=1
and set MaxClients to 5 or 10 so only instances that are actually getting
hit will spawn the extra processes.

I haven't really done side-by-side comparisons.  But yes, I can easily run
20.  I have run 80 instances of Apache on a single machine in the past.
It's really just a question of sticking enough RAM in your box.

Here is a small sample.  The same httpd binary being used across 3

 5269 apache     9   0 11820  11M  6612 S     0.0  2.3   0:01 httpd
 5271 apache     9   0 11816  11M  6608 S     0.0  2.3   0:01 httpd
 7120 apache     9   0 11524  11M  6268 S     0.0  2.2   0:00 httpd

11M processes because they have all sorts of stuff linked in.  But over 6M
of that is shared, so the incremental memory usage for each httpd is about
5M in my case.  For people with less things attached to their Apaches, it
should be quite a bit lower.  But stick a gig of ram in the machine and
you can have about 200 active paged in httpd processes.  So if you only
need to handle 20 instances, or 20 vhosts then each one can have 10 active
connections and your machine should still be happy.  In the real world, on
a shared server you have some vhosts that get hit a lot and a lot more
that don't get hit as often.  So with a gig of ram you should be able to
handle 30-50 virtualhosts I'd say.  Very very rough estimates, of course.
And this assumes a rather beefy httpd with PHP, MySQL, PostgreSQL, LDAP,
SNMP, GD, IMLIB2, Sablotron, expat, pdflib and much more.


On Fri, 21 Jun 2002, Ken Anderson wrote:

> thanks, I found a bit of info at
> Are you able to run more than 20 instances of Apache? How does it
> compare to running 20 processes(StartServers=20)?
> Thanks,
> Ken
> Rasmus Lerdorf wrote:
> > I run Squid on my external ip port 80 and have all my Apaches listening on
> > various ports on
> >
> > Not sure if this is documented somewhere.  It's a pretty basic
> > reverse-proxy SquidGuard setup though.  You really shouldn't need anything
> > except the Squid, SquidGuard and Apache docs.
> >
> > -Rasmus
> >
> > On Fri, 21 Jun 2002, Ken Anderson wrote:
> >
> >
> >>Do you, or does anyone have an documentation on this approach?
> >>Sounds like a good idea for secure php in a shared environment.
> >>Do you run squid on port 80 on the same machine?
> >>Ken Anderson
> >>
> >>
> >>
> >>>However, a nice solution, and the one that I prefer is to use a reverse
> >>>proxy such as Squid out in front of your web server. Then in behind it I
> >>>run multiple instances of Apache as different users on different ports. As
> >>>long as you use the same httpd binary there will be a lot of shared pages,
> >>>and running multiple instances really isn't much more resource-heavy than
> >>>running a single instance with lots of processes.
> >>>
> >>>So the real trick here is that you use something like SquidGuard to
> >>>configure your Squid reverse proxy to send requests for specific virtual
> >>>hosts to the corresponding local port number.  That is, your first Apache
> >>>instance might be configured to listen to, your second
> >>>instance on and so on.  The SquidGuard rules look at the
> >>>Host: header in the requests and direct the requests appropriately.  You
> >>>of course get the added benefit of reverse proxy cacheing which is
> >>>generally a good idea for any busy site anyway.  The biggest change that
> >>>people have to get used to with this sort of architecture is the fact that
> >>>they now have separate configuration files for each Apache instance.  With
> >>>a systematic approach to this, that shouldn't be all that bad.
> >>>
> >>>-Rasmus
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail:
> >>>For additional commands, e-mail:
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail:
> >>For additional commands, e-mail:
> >>
> >
> >
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message