Bandwidth/rate limiting XML-RPC responses on a per method basis

["Volkar, John" <Jo...@McKesson.com>]

I have a method that returns a multi-megabyte byte[].  (This is fine, it
was all in memory anyway; I don't care about the streaming extensions at
this time.)  Right now, when called ,it attempts to use any available
bandwidth to "burp" the response back as fast as possible.  This leads
to spikes in the network traffic.  

I want to throttle the network usage down (rate limit it to say 100kbps)
for *this one method call only* (there are other methods where I want
the response to come back as fast as possible).  I'm using the built-in
WebServer and XmlRpcClient.  

So, two questions:
1) What is the best mechanism to achieve this throttling?
2) Has anyone ever done this, or thought about this?

Thoughts and ideas on where to start is appreciated.

Regards,
John Volkar


John Volkar - Senior Software Engineer
McKesson APS Research & Development 
  
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
 

Re: Bandwidth/rate limiting XML-RPC responses on a per method basis

[Adam Taft <ad...@hydroblaster.com>]

John,

You should probably be considering a reverse proxy sitting in front of 
your XmlRpc server.  There are throttling proxies which will do what 
you're looking to do.  This is probably the most correct solution.

As an example, you could use Apache 1.3 with mod_proxy and mod_bandwidth 
or mod_throttle.  You'd essentially have Apache running as a reverse 
proxy sitting in front of your WebServer and be able to specify 
bandwidth throttling.  (I'm not sure if these modules work with Apache 2)

With Apache, you should be able to use the <Location> or <LocationMatch> 
directive to stipulate that you want bandwidth limiting only on a 
specific URL.  That is, to be able to limit only the XmlRpc method that 
needs throttling.

If your XmlRpcServer was running as a servlet which was running as an 
Apache module (mod_jk, mod_jserv, etc.), then you obviously wouldn't 
need a reverse proxy sitting in front.

For a Java/XmlRpc centric solution, I think the streaming extensions are 
the best way you'll be able to do this.  If you were streaming, you'd be 
able to loop through your byte[] and slow it down with a call to 
Thread.sleep() before sending it out.  It wouldn't be exact, but you'd 
be able to figure out the right combination of the size of byte[] you 
squirt out each iteration and the amount of sleep time you'd need to 
keep your network resources in check.

Finally, if you could, you could break your original byte[] down into 
pieces and have the client request these pieces individually.  If, for 
example, you were to break down the byte[] into say, 100 pieces, just 
the nature of setting up and tearing down 100 connections would slow it 
down.  You could also obviously add some sleep time in the client 
between each piece request (if you have control over the client) or at 
the start of each request in the handler method.  Simply keep the byte[] 
in memory outside of the handler and then only send a portion of it to 
the client.  Obviously, you'd add an argument to the method to specify 
which piece the client is requesting.

Hope this helps.  Food for thought at least.

Adam


Volkar, John wrote:
> I have a method that returns a multi-megabyte byte[].  (This is fine, it
> was all in memory anyway; I don't care about the streaming extensions at
> this time.)  Right now, when called ,it attempts to use any available
> bandwidth to "burp" the response back as fast as possible.  This leads
> to spikes in the network traffic.  
> 
> I want to throttle the network usage down (rate limit it to say 100kbps)
> for *this one method call only* (there are other methods where I want
> the response to come back as fast as possible).  I'm using the built-in
> WebServer and XmlRpcClient.  
> 
> So, two questions:
> 1) What is the best mechanism to achieve this throttling?
> 2) Has anyone ever done this, or thought about this?
> 
> Thoughts and ideas on where to start is appreciated.
> 
> Regards,
> John Volkar
> 
> 
> John Volkar - Senior Software Engineer
> McKesson APS Research & Development 
>   
> Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
>  
>