You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by al...@foogod.com on 2002/08/29 13:53:25 UTC
Questions about filter placement
Greetings all,
A little while back I started working on a module to control bandwidth
utilization with rate limiting, employing fairly flexible configuration and
some other nifty features.. At the time it became clear fairly early on that
it would be much easier to do this properly within the 2.0 API than the
then-current 1.3 server, but the 2.0 API was still somewhat in flux, so after
looking into things a bit I decided to hold off for a little while and come
back to things later.
Now that things are somewhat more solidified I'm coming back and looking at
this project again, but I'm still running into a few questions with the current
2.0 API that I was hoping some folks here could provide some
insight/suggestions on..
>From what I've read about the 2.0 API, this application (rate limiting of
server output) seems perfect for an output filter. However, one of my first
questions centers around where in the filter chain behavior such as this should
go.
Obviously, in order to function properly, this filter should come after any
content-modifying filters in the output chain. Given the fairly low-level
nature of what it's doing (controlling network traffic) it seems to me that it
really makes most sense to put this somewhere in the AP_FTYPE_CONNECTION, or
possibly even AP_FTYPE_NETWORK part of things, however it's my understanding
that connection and network filters do not have access to any information about
the request, and since the bulk of deciding what rate limits are to be imposed
for a given hunk of data is going to be determined by per-resource
configuration, this presents a problem.
I could implement this as an AP_FTYPE_CONTENT_SET filter, which would make the
most sense from a configuration and decision-making standpoint (since I have
access to request information), but one of the questions I have about this is
whether other buffering and such later in the filter chain (such as with
transcode/connection/etc filters) would render any attempts at rate control at
this level moot, or at least seriously degraded.
Ultimately, what seems like the most correct solution I can see would be to
implement this in multiple stages, with one content_set filter used to
determine the appropriate limits for a given set of data, and then a later
filter actually controlling the output rate of that data when it's closer to
going out over the network. The problem with this is that I can't see any
obvious way for the earlier filter to communicate what it's decided about the
given data to the later stage for acting upon. Is there any way to "mark" data
going out from one filter with information that can be used by a later filter
when it gets that data to work on?
Anyway, does anybody out there have suggestions on the best approach to use for
this application? Where should code to control data flow rate go in the filter
chain, and if that place isn't in a request-related filter, is there an easy
way to make request-level decisions related to that filtering?
Thanks,
-alex
PS: As this subject seems to be a hotbutton for some people (at least it was
the last time I brought it up on this list), please don't just respond to this
by saying "why would you want to do that?" or "bandwidth limiting doesn't
belong in the httpd server!" or "people have already made things that do that"
or similar things. I've had all these discussions before, and I have good
reasons for making this module that I'll be happy to explain to people in
private if you really want to understand where I'm coming from with this, but
ultimately it boils down to: Yes, this is required to do things which you
really can't do other ways and is potentially very useful. No, nobody else has
already done it with the capabilities I'm looking for (I've checked).
Re: Questions about filter placement
Posted by Bojan Smojver <bo...@rexursive.com>.
On Fri, 2002-08-30 at 10:05, alex@foogod.com wrote:
> Most of this code isn't even out of my head yet, give me a chance to scribble
> some of it down before you all try to test it! :)
Having that thingy from Johnny Mnemonic, would help during that phase, I
reckon ;-) Happy hacking!
Bojan
Re: Questions about filter placement
Posted by al...@foogod.com.
On Fri, Aug 30, 2002 at 09:58:01AM +1000, Bojan Smojver wrote:
> On Fri, 2002-08-30 at 09:46, alex@foogod.com wrote:
>
> > I'll let people know when I have something people might actually want to use :)
>
> I don't know if you're planning to make this module free software, but
> if you do - treat your users as developers and they will be the
> developers :-)
Oh, trust me, I'm a long-time open source advocate, and I've intended to
release this under the Apache license from the beginning. What I meant by
"something people might actually want to use" was really along the lines of
"something that at least compiles"..
Most of this code isn't even out of my head yet, give me a chance to scribble
some of it down before you all try to test it! :)
-alex
Re: Questions about filter placement
Posted by Bojan Smojver <bo...@rexursive.com>.
On Fri, 2002-08-30 at 09:46, alex@foogod.com wrote:
> I'll let people know when I have something people might actually want to use :)
I don't know if you're planning to make this module free software, but
if you do - treat your users as developers and they will be the
developers :-)
Bojan
Re: Questions about filter placement
Posted by al...@foogod.com.
On Fri, Aug 30, 2002 at 01:31:04AM +0200, Werner Schalk wrote:
> tell me more about your module.
> Is it already available for testing
> and apache2?
Nope, as I mentioned, I've got the core decision-making code (and the
rate-limiting theory) written, but I'm just starting to put together an apache
module around it so it can actually be used with the apache server.
I hope to have a basic prototype reasonably soon, tho, if I don't run into big
problems figuring out how to write the apache code. It may be a bit longer
before it supports all the options I mentioned in my description.
I'll let people know when I have something people might actually want to use :)
-alex
> On Thu, Aug 29, 2002 at 08:06:45AM -0700, Ian Holsman wrote:
> > your trying to limit traffic based on what kind of request/request
> > path
> > it has ?
>
> Yes, actually based on vhost, URI, directory, file type, size, user,
> time of day, etc, etc.. pretty much anything you can think of. It also
> supports multiple overlapping bandwidth restrictions and will restrict
> traffic based on what other requests are currently being served to
> ensure the cumulative rate for any given bandwidth limit is never
> exceeded.
>
> I've got the core code working in a test harness, now I just need to put
> it into an apache module..
Re: Questions about filter placement
Posted by al...@foogod.com.
On Thu, Aug 29, 2002 at 04:55:57PM -0700, Ian Holsman wrote:
> hmm
> you might run into trouble on filetype/size (anything which you need the
> response for) as there is no hook >after< the handler.
Hmm, that's a little annoying.. I'm actually realizing that I probably can't
do it cleanly based on size in any case (I was originally thinking of just
looking at the file size of whatever file the request mapped to, but that
doesn't do anything for non-file-backed requests, which means inconsistent
behavior, which is bad. I'm not sure there would be a lot of demand for rate
limiting based on response size anyway, tho, so I'll probably just leave that
out for the time being.
I would really like to be able to do limits based on content type, though. It
sounds like this might actually require inserting an output filter for
decision-making, so it would have access to that information. Is there a way
for filters to remove themselves from the chain partway through serving a
request? That way, at least, it could check things once on the initial call
and then get out of the way for the rest of the output..
> I'm not sure if a EOS gets as far as the CORE-OUT if it does that is
> what you'll need to check for.
Yeah, that was one of the things I wasn't sure about.. I guess I'll just have
to play it by ear..
Another option, I suppose, would just be to consider a request "done" when
either another request comes through on the connection, or the connection is
closed. That's kinda ugly, tho, because theoretically a client could hold a
keepalive connection open long after the last request has finished, and
bandwidth would still be being allocated for it.. hmph.
-alex
Re: Questions about filter placement
Posted by Ian Holsman <ia...@apache.org>.
alex@foogod.com wrote:
> On Thu, Aug 29, 2002 at 08:06:45AM -0700, Ian Holsman wrote:
>
>>your trying to limit traffic based on what kind of request/request path
>>it has ?
>
>
> Yes, actually based on vhost, URI, directory, file type, size, user, time of
> day, etc, etc.. pretty much anything you can think of. It also supports
> multiple overlapping bandwidth restrictions and will restrict traffic based on
> what other requests are currently being served to ensure the cumulative rate
> for any given bandwidth limit is never exceeded.
hmm
you might run into trouble on filetype/size (anything which you need the
response for) as there is no hook >after< the handler.
>
> I've got the core code working in a test harness, now I just need to put it
> into an apache module..
>
>
>>>I could implement this as an AP_FTYPE_CONTENT_SET filter, which would make the
>>>most sense from a configuration and decision-making standpoint (since I have
>>>access to request information), but one of the questions I have about this is
>>>whether other buffering and such later in the filter chain (such as with
>>>transcode/connection/etc filters) would render any attempts at rate control at
>>>this level moot, or at least seriously degraded.
>>
>>yes, but from what I can see if you are trying to slow down the request
>>with your filter, this should not be a major drama.
>
>
> Well, my main concern is if there are things down the line which buffer large
> portions of data before sending them out, it would generate "bursty" network
> traffic, which I want to avoid. Part of the reason I'm doing this is because I
> want to have more smooth control of network utilization so it doesn't impact
> other services or requests..
>
> I had seen some notes about the content-length filter, for example, setting
> aside the entire response until it got the end of it, which if my filter was
> before it would completely defeat the behavior of my rate limiting..
>
>
>>if you are basing the rate limiting on something on the request I would
>>suggest you write a request hook, (somewhere after the request headers
>>have been read.. forget the name for the moment) and make it set a note
>>in the connection record. (or maybe use the apr_pool_userdata_set(pool)
>>call it's faster)
>
>
> Ah, thank you.. Yeah, I realize now I should have been thinking in terms of a
> request hook rather than a filter for the decision-making process, but aside
> from that little detail this is basically what I was envisioning. I wasn't
> aware of apr_pool_userdata_set or connection record notes, I'll go look into
> that. It sounds like it should do very much what I'm looking for.
>
> One last question: Because it keeps track of what other requests are currently
> being served, my implementation needs to know when serving a request has been
> completed, as well. Obviously, this could pose some problems with coordination
> between when request-processing is considered finished and when the data
> actually goes out over the net. What I would really like to do is consider a
> request "finished" once the last of its data goes out. Is there an appropriate
> hook or something for doing stuff when this happens, or should I just look for
> an EOS or something go through my limiting filter and do the processing there?
>
I'm not sure if a EOS gets as far as the CORE-OUT if it does that is
what you'll need to check for.
> I'm still getting the hang of a lot of this architecture, but I'd like to do
> things The Correct Way(tm) if possible :)
>
>
>>The only potential downside I can with implementing it this way is if
>>you have 2 small requests which get sent out together, you will get the
>>rate limit of the 2nd one.
>
>
> As long as they're small, I don't think anybody will care that much, so I can
> live with that.
>
> Thanks a lot for the help,
>
> -alex
>
Re: Questions about filter placement
Posted by al...@foogod.com.
On Thu, Aug 29, 2002 at 05:10:00PM -0700, Brian Pane wrote:
> Another possibility would be to create a new metadata bucket type.
> In a request-level hook or filter, insert a metadata bucket that
> describes the appropriate bandwidth-throttling rules for the buckets
> that follow. Then you can use a connection-level filter to do the
> actual throttling; that filter, which won't otherwise have access
> to request-level information, can look at the metadata buckets to
> figure out what bandwidth limit to apply.
Ooh! I like this.. this might also help with the problem of determining when a
request is "done", too.. thanks for the suggestion, I'll look into this too.
-alex
Re: Questions about filter placement
Posted by Brian Pane <br...@apache.org>.
alex@foogod.com wrote:
>Well, my main concern is if there are things down the line which buffer large
>portions of data before sending them out, it would generate "bursty" network
>traffic, which I want to avoid. Part of the reason I'm doing this is because I
>want to have more smooth control of network utilization so it doesn't impact
>other services or requests..
>
>I had seen some notes about the content-length filter, for example, setting
>aside the entire response until it got the end of it, which if my filter was
>before it would completely defeat the behavior of my rate limiting..
>
In the specific case of the content-length filter, the problem is now
fixed; as of a change I committed yesterday, it no longer tries to buffer
the entire response. In general, I think we should avoid letting any
filter buffer an unbounded amount of data like the C-L filter used to
do.
>>if you are basing the rate limiting on something on the request I would
>>suggest you write a request hook, (somewhere after the request headers
>>have been read.. forget the name for the moment) and make it set a note
>>in the connection record. (or maybe use the apr_pool_userdata_set(pool)
>>call it's faster)
>>
Another possibility would be to create a new metadata bucket type.
In a request-level hook or filter, insert a metadata bucket that
describes the appropriate bandwidth-throttling rules for the buckets
that follow. Then you can use a connection-level filter to do the
actual throttling; that filter, which won't otherwise have access
to request-level information, can look at the metadata buckets to
figure out what bandwidth limit to apply.
Brian
Re: Questions about filter placement
Posted by Ian Holsman <ia...@apache.org>.
alex@foogod.com wrote:
> On Thu, Aug 29, 2002 at 08:06:45AM -0700, Ian Holsman wrote:
>
>>your trying to limit traffic based on what kind of request/request path
>>it has ?
>
>
> Yes, actually based on vhost, URI, directory, file type, size, user, time of
> day, etc, etc.. pretty much anything you can think of. It also supports
> multiple overlapping bandwidth restrictions and will restrict traffic based on
> what other requests are currently being served to ensure the cumulative rate
> for any given bandwidth limit is never exceeded.
hmm
you might run into trouble on filetype/size (anything which you need the
response for) as there is no hook >after< the handler.
>
> I've got the core code working in a test harness, now I just need to put it
> into an apache module..
>
>
>>>I could implement this as an AP_FTYPE_CONTENT_SET filter, which would make the
>>>most sense from a configuration and decision-making standpoint (since I have
>>>access to request information), but one of the questions I have about this is
>>>whether other buffering and such later in the filter chain (such as with
>>>transcode/connection/etc filters) would render any attempts at rate control at
>>>this level moot, or at least seriously degraded.
>>
>>yes, but from what I can see if you are trying to slow down the request
>>with your filter, this should not be a major drama.
>
>
> Well, my main concern is if there are things down the line which buffer large
> portions of data before sending them out, it would generate "bursty" network
> traffic, which I want to avoid. Part of the reason I'm doing this is because I
> want to have more smooth control of network utilization so it doesn't impact
> other services or requests..
>
> I had seen some notes about the content-length filter, for example, setting
> aside the entire response until it got the end of it, which if my filter was
> before it would completely defeat the behavior of my rate limiting..
>
>
>>if you are basing the rate limiting on something on the request I would
>>suggest you write a request hook, (somewhere after the request headers
>>have been read.. forget the name for the moment) and make it set a note
>>in the connection record. (or maybe use the apr_pool_userdata_set(pool)
>>call it's faster)
>
>
> Ah, thank you.. Yeah, I realize now I should have been thinking in terms of a
> request hook rather than a filter for the decision-making process, but aside
> from that little detail this is basically what I was envisioning. I wasn't
> aware of apr_pool_userdata_set or connection record notes, I'll go look into
> that. It sounds like it should do very much what I'm looking for.
>
> One last question: Because it keeps track of what other requests are currently
> being served, my implementation needs to know when serving a request has been
> completed, as well. Obviously, this could pose some problems with coordination
> between when request-processing is considered finished and when the data
> actually goes out over the net. What I would really like to do is consider a
> request "finished" once the last of its data goes out. Is there an appropriate
> hook or something for doing stuff when this happens, or should I just look for
> an EOS or something go through my limiting filter and do the processing there?
>
I'm not sure if a EOS gets as far as the CORE-OUT if it does that is
what you'll need to check for.
> I'm still getting the hang of a lot of this architecture, but I'd like to do
> things The Correct Way(tm) if possible :)
>
>
>>The only potential downside I can with implementing it this way is if
>>you have 2 small requests which get sent out together, you will get the
>>rate limit of the 2nd one.
>
>
> As long as they're small, I don't think anybody will care that much, so I can
> live with that.
>
> Thanks a lot for the help,
>
> -alex
>
RE: Questions about filter placement
Posted by Werner Schalk <we...@gmx.de>.
Hello Alex,
tell me more about your module.
Is it already available for testing
and apache2?
Bye and thanks,
Werner.
-----Original Message-----
From: alex@foogod.com [mailto:alex@foogod.com]
Sent: Friday, August 30, 2002 1:23 AM
To: dev@httpd.apache.org
Subject: Re: Questions about filter placement
On Thu, Aug 29, 2002 at 08:06:45AM -0700, Ian Holsman wrote:
> your trying to limit traffic based on what kind of request/request
> path
> it has ?
Yes, actually based on vhost, URI, directory, file type, size, user,
time of day, etc, etc.. pretty much anything you can think of. It also
supports multiple overlapping bandwidth restrictions and will restrict
traffic based on what other requests are currently being served to
ensure the cumulative rate for any given bandwidth limit is never
exceeded.
I've got the core code working in a test harness, now I just need to put
it into an apache module..
> > I could implement this as an AP_FTYPE_CONTENT_SET filter, which
> > would make the most sense from a configuration and decision-making
> > standpoint (since I have access to request information), but one of
> > the questions I have about this is whether other buffering and such
> > later in the filter chain (such as with transcode/connection/etc
> > filters) would render any attempts at rate control at this level
> > moot, or at least seriously degraded.
>
> yes, but from what I can see if you are trying to slow down the
> request
> with your filter, this should not be a major drama.
Well, my main concern is if there are things down the line which buffer
large portions of data before sending them out, it would generate
"bursty" network traffic, which I want to avoid. Part of the reason I'm
doing this is because I want to have more smooth control of network
utilization so it doesn't impact other services or requests..
I had seen some notes about the content-length filter, for example,
setting aside the entire response until it got the end of it, which if
my filter was before it would completely defeat the behavior of my rate
limiting..
> if you are basing the rate limiting on something on the request I
> would
> suggest you write a request hook, (somewhere after the request headers
> have been read.. forget the name for the moment) and make it set a
note
> in the connection record. (or maybe use the
apr_pool_userdata_set(pool)
> call it's faster)
Ah, thank you.. Yeah, I realize now I should have been thinking in
terms of a request hook rather than a filter for the decision-making
process, but aside from that little detail this is basically what I was
envisioning. I wasn't aware of apr_pool_userdata_set or connection
record notes, I'll go look into that. It sounds like it should do very
much what I'm looking for.
One last question: Because it keeps track of what other requests are
currently being served, my implementation needs to know when serving a
request has been completed, as well. Obviously, this could pose some
problems with coordination between when request-processing is considered
finished and when the data actually goes out over the net. What I would
really like to do is consider a request "finished" once the last of its
data goes out. Is there an appropriate hook or something for doing
stuff when this happens, or should I just look for an EOS or something
go through my limiting filter and do the processing there?
I'm still getting the hang of a lot of this architecture, but I'd like
to do things The Correct Way(tm) if possible :)
> The only potential downside I can with implementing it this way is if
> you have 2 small requests which get sent out together, you will get
the
> rate limit of the 2nd one.
As long as they're small, I don't think anybody will care that much, so
I can live with that.
Thanks a lot for the help,
-alex
Re: Questions about filter placement
Posted by al...@foogod.com.
On Thu, Aug 29, 2002 at 08:06:45AM -0700, Ian Holsman wrote:
> your trying to limit traffic based on what kind of request/request path
> it has ?
Yes, actually based on vhost, URI, directory, file type, size, user, time of
day, etc, etc.. pretty much anything you can think of. It also supports
multiple overlapping bandwidth restrictions and will restrict traffic based on
what other requests are currently being served to ensure the cumulative rate
for any given bandwidth limit is never exceeded.
I've got the core code working in a test harness, now I just need to put it
into an apache module..
> > I could implement this as an AP_FTYPE_CONTENT_SET filter, which would make the
> > most sense from a configuration and decision-making standpoint (since I have
> > access to request information), but one of the questions I have about this is
> > whether other buffering and such later in the filter chain (such as with
> > transcode/connection/etc filters) would render any attempts at rate control at
> > this level moot, or at least seriously degraded.
>
> yes, but from what I can see if you are trying to slow down the request
> with your filter, this should not be a major drama.
Well, my main concern is if there are things down the line which buffer large
portions of data before sending them out, it would generate "bursty" network
traffic, which I want to avoid. Part of the reason I'm doing this is because I
want to have more smooth control of network utilization so it doesn't impact
other services or requests..
I had seen some notes about the content-length filter, for example, setting
aside the entire response until it got the end of it, which if my filter was
before it would completely defeat the behavior of my rate limiting..
> if you are basing the rate limiting on something on the request I would
> suggest you write a request hook, (somewhere after the request headers
> have been read.. forget the name for the moment) and make it set a note
> in the connection record. (or maybe use the apr_pool_userdata_set(pool)
> call it's faster)
Ah, thank you.. Yeah, I realize now I should have been thinking in terms of a
request hook rather than a filter for the decision-making process, but aside
from that little detail this is basically what I was envisioning. I wasn't
aware of apr_pool_userdata_set or connection record notes, I'll go look into
that. It sounds like it should do very much what I'm looking for.
One last question: Because it keeps track of what other requests are currently
being served, my implementation needs to know when serving a request has been
completed, as well. Obviously, this could pose some problems with coordination
between when request-processing is considered finished and when the data
actually goes out over the net. What I would really like to do is consider a
request "finished" once the last of its data goes out. Is there an appropriate
hook or something for doing stuff when this happens, or should I just look for
an EOS or something go through my limiting filter and do the processing there?
I'm still getting the hang of a lot of this architecture, but I'd like to do
things The Correct Way(tm) if possible :)
> The only potential downside I can with implementing it this way is if
> you have 2 small requests which get sent out together, you will get the
> rate limit of the 2nd one.
As long as they're small, I don't think anybody will care that much, so I can
live with that.
Thanks a lot for the help,
-alex
Re: Questions about filter placement
Posted by Ian Holsman <ia...@apache.org>.
alex@foogod.com wrote:
> Greetings all,
>
<snip>
> From what I've read about the 2.0 API, this application (rate limiting of
> server output) seems perfect for an output filter. However, one of my first
> questions centers around where in the filter chain behavior such as this should
> go.
>
> Obviously, in order to function properly, this filter should come after any
> content-modifying filters in the output chain. Given the fairly low-level
> nature of what it's doing (controlling network traffic) it seems to me that it
> really makes most sense to put this somewhere in the AP_FTYPE_CONNECTION, or
> possibly even AP_FTYPE_NETWORK part of things, however it's my understanding
> that connection and network filters do not have access to any information about
> the request, and since the bulk of deciding what rate limits are to be imposed
> for a given hunk of data is going to be determined by per-resource
> configuration, this presents a problem.
>
your trying to limit traffic based on what kind of request/request path
it has ?
> I could implement this as an AP_FTYPE_CONTENT_SET filter, which would make the
> most sense from a configuration and decision-making standpoint (since I have
> access to request information), but one of the questions I have about this is
> whether other buffering and such later in the filter chain (such as with
> transcode/connection/etc filters) would render any attempts at rate control at
> this level moot, or at least seriously degraded.
yes, but from what I can see if you are trying to slow down the request
with your filter, this should not be a major drama.
>
> Ultimately, what seems like the most correct solution I can see would be to
> implement this in multiple stages, with one content_set filter used to
> determine the appropriate limits for a given set of data, and then a later
> filter actually controlling the output rate of that data when it's closer to
> going out over the network. The problem with this is that I can't see any
> obvious way for the earlier filter to communicate what it's decided about the
> given data to the later stage for acting upon. Is there any way to "mark" data
> going out from one filter with information that can be used by a later filter
> when it gets that data to work on?
if you are basing the rate limiting on something on the request I would
suggest you write a request hook, (somewhere after the request headers
have been read.. forget the name for the moment) and make it set a note
in the connection record. (or maybe use the apr_pool_userdata_set(pool)
call it's faster)
this hook could also insert your output filter, I would think it would
make most sense for your filter to be between CORE_OUT & CONTENT_LENGTH
or just before CONTENT_LENGTH depending on how you want to handle
keep-alives.
your filter can access the connection's notes table so your set (as far
as data passing is concerned)
I would set it just before CORE_OUT, giving you full control, and making
sure that your hook doesn't insert it twice, the only downside is that
you would need to check the note value everytime your filter got called.
The only potential downside I can with implementing it this way is if
you have 2 small requests which get sent out together, you will get the
rate limit of the 2nd one.
>
> Anyway, does anybody out there have suggestions on the best approach to use for
> this application? Where should code to control data flow rate go in the filter
> chain, and if that place isn't in a request-related filter, is there an easy
> way to make request-level decisions related to that filtering?
>
> Thanks,
>
> -alex
>
> PS: As this subject seems to be a hotbutton for some people (at least it was
> the last time I brought it up on this list), please don't just respond to this
> by saying "why would you want to do that?" or "bandwidth limiting doesn't
> belong in the httpd server!" or "people have already made things that do that"
> or similar things. I've had all these discussions before, and I have good
> reasons for making this module that I'll be happy to explain to people in
> private if you really want to understand where I'm coming from with this, but
> ultimately it boils down to: Yes, this is required to do things which you
> really can't do other ways and is potentially very useful. No, nobody else has
> already done it with the capabilities I'm looking for (I've checked).
>