httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Morris <supp...@bettercgi.com>
Subject Re: Bandwith limit/per user from mysql
Date Thu, 10 Dec 2009 00:38:18 GMT
    Yeah, there aren't a lot of options, and what else
there is other than Throttlebox is far more simplistic.
We wrote Throttlebox because we found that the existing
solutions were a tad TOO simplistic - they caused just
enough problems to not be worth it for the benefits.
It took a few years of experimenting and thinking, but
it seems to work pretty well now, and it has support
for different formulas to be easily added in.  Certainly
it costs a lot less than the developer time to design,
implement, test, redesign, reimplement either home grown
module OR the admin interface to go with it.
--
Ray Morris
support@bettercgi.com

Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/

Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/

Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php


On 12/09/2009 11:11:40 AM, partysoft wrote:
> 
> Ok, i see that's a complete solution, i like it, let me check with my  
> bosses
> to get the money for this , but probably we will go for it, as we  
> haven't
> found any solution so far but this one you suggested
> 
> Ray Morris wrote:
> >
> >
> >
> >> > This kind of functionality,  in my opinion, is better
> >> > implemented at transport level and not at application level.
> >
> >> Yes, well that was the main problem , doing it per user, of course  
> i
> >> have on
> >> the DB the ips of the users when they login, i even update that,  
> but
> >> you
> >> know how ips are, constantly changing, even more, they can be under
> >> NAT on
> >> some private network,
> >> but no doubt making it under a lower OSI level would be great and
> >> have a
> >> good performance..
> >> but i will have to rewrite the ipchains constantly...
> >
> >
> >     Indeed we sometimes see IPs change several times
> > within a 15 minute window, and this will become more
> > common as IPv6 is more widely used.
> >
> >    Also, the point is to solve a business problem.
> > It's technical solution to a business problem, so you
> > have to think in terms of business as well as technically.
> > When someone purchases downloads as in this application,
> > you're looking at bandwidth over a period of time beyond the
> > current instant.  It's not that you're wanting to make the site
> > sluggish for users, but that you want to control the abusive
> > users.  So isn't bits per second that is best controlled, but
> > MB per hour or GB per 48 hours.  You also MUST consider protocol
> > specific considerations in order to have an effective solution
> > to the business issue.  One small example is that you want to
> > control the download of the mp3 files, not make the site slow
> > by causing the web page graphics to be slow or not load.
> > The technician, thinking purely techincally, might just
> > tc queuing policy, but they would be rightly lambasted by
> > the business manager for making the sluggish rather than
> > addressing the actual concern, which includes an appropriate
> > message to the user.
> > --
> > Ray Morris
> > support@bettercgi.com
> >
> > Strongbox - The next generation in site security:
> > http://www.bettercgi.com/strongbox/
> >
> > Throttlebox - Intelligent Bandwidth Control
> > http://www.bettercgi.com/throttlebox/
> >
> > Strongbox / Throttlebox affiliate program:
> > http://www.bettercgi.com/affiliates/user/register.php
> >
> >
> > On 12/08/2009 05:48:37 PM, partysoft wrote:
> >>
> >> Yes, well that was the main problem , doing it per user, of course  
> i
> >> have on
> >> the DB the ips of the users when they login, i even update that,  
> but
> >> you
> >> know how ips are, constantly changing, even more, they can be under
> >> NAT on
> >> some private network,
> >> but no doubt making it under a lower OSI level would be great and
> >> have a
> >> good performance..
> >> but i will have to rewrite the ipchains constantly...
> >>
> >>
> >> Sorin Manolache wrote:
> >> >
> >> > On Tue, Dec 8, 2009 at 05:11, partysoft <partysoft@gmail.com>  
> wrote:
> >> >>
> >> >> I am looking for a solution to limit the bandwith for the users  
> of
> >> a site
> >> >> that have access to some mp3 / subscription. I don't want to  
> serve
> >> files
> >> >> through PHP, but directly with some apache module..
> >> >> do i have to count every bit? or how this should be handled. I
> >> have all
> >> >> the
> >> >> info on a mysql DB.
> >> >> Thank you so much for your replies.
> >> >
> >> > This kind of functionality,  in my opinion, is better  
> implemented at
> >> > transport level and not at application level.
> >> >
> >> > I've done something similar, but more primitive, i.e. the  
> cumulated
> >> > bandwidth of all connections to port 80 was capped, using traffic
> >> > shaping in the linux kernel.
> >> >
> >> > The network packets are classified with iptables and then each  
> class
> >> > can be given a different queueing policy with tc. Check
> >> > http://lartc.org/howto/, chapter 9. I didn't do it per user, but  
> I
> >> > suppose one can easily do it per client IP address. I admit that
> >> maybe
> >> > this approach is not suitable when you identify users with some  
> data
> >> > token at application level.
> >> >
> >> > S
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>  
> http://old.nabble.com/Bandwith-limit-per-user-from-mysql-tp26688437p26702936.html
> >> Sent from the Apache HTTP Server - Module Writers mailing list
> >> archive at Nabble.com.
> >>
> >>
> >
> >
> >
> 
> --
> View this message in context:  
> http://old.nabble.com/Bandwith-limit-per-user-from-mysql-tp26688437p26713855.html
> Sent from the Apache HTTP Server - Module Writers mailing list  
> archive at Nabble.com.
> 
> 


Mime
View raw message