On Fri, 2001-08-31 at 13:40, Jason Burns/DHD wrote:
>
> Once again, Danni's Hard Drive has implemented these features in apache
> 1.3.x.
> I sent in a patch to 1.3.20 but nobody has appeared to be interested in it.
> I feel like this is the SGI 10x patch deal all over again. Would anyone
> care
> to look at the patch if I sent it in again?
>
hi Jason.
the apache group at the moment isn't really interested in
adding new features to the 1.3.X server.
there concentrating on getting the 2.0 release out.
I don't have commit access to the apache tree, but I assure you they do
look at the patches and sometimes they might even implement them ;-)
(do you have a bandwith module for 2.0.X ???)
> Jason
>
>
>
>
>
> Charles Randall
>
> <crandall@match To: "'[EMAIL PROTECTED]'"
><[EMAIL PROTECTED]>
> logic.com> cc:
>
> Subject: RE: Bandwidth control
>
> 08/31/01 10:26
>
> AM
>
> Please respond
>
> to dev
>
>
>
>
>
>
>
>
>
> As you point out, that level of granularity isn't available with general
> purpose traffic shaping tools.
>
> You may want to look at the Zeus server to understand the features that
> were
> product-worthy as one example. It appears that they've only implemented
> this
> at the virtual server level.
>
> As you're probably aware, thttpd also provides flexible bandwidth
> throttling,
>
> http://www.acme.com/software/thttpd/thttpd_man.html#THROTTLING
>
> Charles
>
> -----Original Message-----
> From: Alex Stewart [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 30, 2001 5:53 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bandwidth control
>
>
> Charles Randall wrote:
> > Often times, this can be done easier at the OS level. What OS are you
> using?
>
> Linux, and I am aware of various kernel-level controls for traffic
> shaping, etc, however if you can tell me how to enforce different
> bandwidth limits for different name-based vhosts, different directories,
> etc, then I'm all ears, but I suspect I can also give you pretty good
> reasons why even if such decisions could somehow be done at the OS
> level, they really shouldn't be.
>
> -alex
>
>
>
--
Ian Holsman [EMAIL PROTECTED]
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
