I think that the main problem with too many VitualHost in apache is how
many descriptors (file handles) it opens...
from http://httpd.apache.org/docs/misc/descriptors.html
-----
A descriptor, also commonly called a file handle is an object that a
program uses to read or write an open file, or open network socket, or a
variety of other devices. It is represented by an integer, and you may be
familiar with stdin, stdout, and stderr which are descriptors 0, 1, and 2
respectively. Apache needs a descriptor for each log file, plus one for
each network socket that it listens on, plus a handful of
others. Libraries that Apache uses may also require descriptors. Normal
programs don't open up many descriptors at all, and so there are some
latent problems that you may experience should you start running Apache
with many descriptors (i.e., with many virtual hosts).
-----
in other words... if we use a different error/access log file for each
VitualHost (time many VS's)... and enough child processes in each VS
serving different requests... there is a chance of running out of
descriptors (and I suppose... the system could crash? or would it be
apache?)....
One mitigating solution apache offers is to use only 1 access_log and 1
error_log... their implementation is as follows:
(from http://www.apache.org/docs-2.0/vhosts/mass.html) (and I just
checked... it is implemented at least in ver 1.3)
LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
At least with the LogFormat as above one can save resources... not only
file handles but also memory...
(then with a simple script, running form cron, it is easy to redistribute
the crude logs to each client, or, better still... using webalizer one can
generate at once all the reports)
the problem is how to enforce a policy... because the client could place
a log directive within the <VitualHost></VitualHost> ...
In our case what we will do for now is to run a very simple script from
the host that will count the number of times that log is mentioned in each
httpd.conf .. and if more than 1 for each type.... will send us an email
:).. BTW.. that could be a very rudimentary way of "enforcing" a maximum
number of VitualHost per VS (you could even disable apache through the
script)
finally... a question....
with the "old" structure of 2 httpd.conf (one owned by root.root in etc/
the other called by the first one in /etc/httpd/conf/)... if we have
something like : MaxClients 25 in the first one (root.root), and in the
second one the admin puts MaxClients 256 ... which one will be honored?
(yes... of course that could also be checked by a script.. but I was
wondering ;)
Cheers!
Marcos
(trying to set up another server to experiment upgrading to rh-7.1 and the
latest freevsd... hopefully soon... after all the problems we had trying
to upgrade the last time around --long, long ago, we won't dare to do it
in the production server before a few "dry runs" ;)
On Thu, 7 Jun 2001, Tim Sellar wrote:
> We are actively investigating implementing dynamic limitations on features
> such as cpu/memory but to be done properly we favour implmenting a secure
> patch to the kernel and producing an improved scheduler. With respect to
> limiting http and mysql connections, can't that sort of thing be done using
> xinetd? Perhaps we need a mod_xinetd?
>
> Tim
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Gary Reid
> > Sent: 07 June 2001 12:22
> > To: [EMAIL PROTECTED]
> > Subject: quality of service levels
> >
> >
> > has anyone sucessfully put limits on a VS? cpu, memory, http connections,
> > mysql connections etc etc - so as to give a quality of service guarantee -
> > we could set some in httpd.conf but as VS admin has access to
> > this it's not
> > such a good idea
> >
> > Also how has anyone limited the actual number of virtual domains a VS can
> > add to the webserver? Additions to name servers are covered but customers
> > could use public dns etc
> >
> > Gary
> >
>
