httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joshua Slive" <>
Subject Re: Vhosts running as different userids (was: Re: Inclusion of mpm-itk into HEAD)
Date Sun, 05 Aug 2007 14:21:49 GMT
On 8/5/07, Vegard Svanberg <> wrote:
> * William A. Rowe, Jr. <> [2007-08-05 05:15]:
> > > I've looked through the archives, but have not seen this mentioned again
> > > since then. I was wondering if this has been discussed any further,
> > > possibly moved to other mailing lists, and/or if it's been added to a
> > > roadmap for future releases.
> >
> > None of the above.  There has been activity on the
> > site w.r.t. setting up per-user hosts in parallel, but not much else.
> OK. Say you have a server with 1000 vhosts, what performance penalties
> must be expected from this solution? Just more memory (and if so,
> roughly how much)?

This question might be better answered on the users list.

There is no single answer to that, because it depends on exactly what
kind of hosts we are talking about. But in general, 1000 is too many
hosts for true isolation on a single box. That is because any
decently-performing isolation solution involves keeping a pool of
threads/processes available under each userid. And 1000 pools of
threads or processes is really going to be at the limit of any
reasonable hardware/software. Of course, you could spread the
back-ends among many boxes if you wanted, but then it isn't a true
name-based virtual hosting solution.

So what you are asking about is more a general architecture question
than a specific apache configuration issue.

But to answer your specific question, if you were serving only static
content, then the proxy solution is probably going to use
approximately twice as much resources as a standard vhosting setup.
But I would expect that normally you are talking about somewhat
heavy-weight back-ends. In this case, you will use substantially less
than twice as much resources, because the front-end can be very
light-weight. Again, there is no single answer.


> > It takes a specific developer hacking at a solution, and for the developer
> > to respond to the concerns/criticisms, to ultimately end up with code that
> > we might incorporate in svn trunk.
> Yes, I'm aware of that. One of the reasons for asking was to check if
> this is the preferred way of "fixing this problem" or if there are other
> (possibly better) suggestions out there.
> Thank you for your replies.
> --
> Vegard Svanberg <> [*Takapa@IRC (EFnet)]

View raw message