[prev in list] [next in list] [prev in thread] [next in thread] 

List:       inn-workers
Subject:    Re: concurrency
From:       Nick Edwards <nick.z.edwards () gmail ! com>
Date:       2014-09-13 16:13:27
Message-ID: CAMD-=VLttv6h=jzFSRUXY1m5AWs4rTkBXmk5LBPHg6e1+ixO-w () mail ! gmail ! com
[Download RAW message or body]

On 9/13/14, Julien ÉLIE <julien@trigofacile.com> wrote:
> Hi Nick,
>
>>>> So far, inn working well, but I need to do two things, firstly, limit
>>>> max user concurrency (8) at any given time, the closest I can find is
>>>> running innd with -H -X which does not sound appropriate,
>>>
>>> I believe you should do that with a Perl or Python auth hook.
>>
>> Oh, really? wow, hard to imagine inn's been around for so long without
>> basic features
>
> I bet the reason is that it is very easy to do what you want to achieve
> with the very efficient Perl hooks facilities INN provides.
>

perl and efficient should never be used together when it comes to
system resource usage :)
especially like this, when you have on average 3100 concurrent users
on a server, I'd hate to see the load on the box if I had to run that
script :-)

> After a few searches on Google, I found out a bit of code written by
> Frédéric Senault:
>      http://news.lacave.net/inn/auth_rate.pl
>
> For your needs, this code should be run at access time (instead of auth
> time).
>
> He basically checks user concurrency this way:
>
>    my $oc = 0;
>
>    open(P, '/bin/ps -ax |') && do {
>      while(<P>) {
>        if(/nnrpd: (\S*)/) {
>          if($1 eq $attributes{hostname}) {
>            $oc++;
>          }
>        }
>      }
>      close(P);
>    };
>
>    if($oc > $MAX) {
>      sleep(2);
>      return ( '502', 'Too many connections from your host' );
>    }
>
>
>
>> my manager has already questioned why it has taken so long, he's
>> very relaxed with time management, else I would have been ordered to
>> dump inn 5 days ago, but even his patience is running dry, all these
>> hassles when with dnews its simple as adding into access.conf
> [...]
>> inn is so so so much more complex and although free
>
> I confess INN is not "newbie-friendly" as you also say but on the other
> hand, you can customize it and achieve pretty interesting and powerful
> things with its hooks facilities (in Perl or Python).
> Well, of course it implies that you know such languages, though they are
> not in fact complex (see the previous Perl code).
>
>
>
> Regarding the other dnews extensions you mention (quota, input/output
> bandwidth speed...), and even the one discussed here, I see in our
> inn-workers archives that we talked about them:
>    https://lists.isc.org/pipermail/inn-workers/2003-September/012063.html
>    https://lists.isc.org/pipermail/inn-workers/2000-July/003386.html
>
> It appears that the best way to do that is the use of xinetd (or a
> similar utility).  You then get a few handy features for controlling
> access at the TCP level and also get the advantage of any further
> improvements in those programs.
> "No need to reinvent the wheel." :)

spawning from xinetd or tcpserver  is far from optimum with so many
users (we learnt that in old days with qmail, vpopmail, and so on,
dnews re-invented that wheel because it clearly needed to be, and
given the load on that 32bit server rarely exceeds above .70 it
clearly does it nicely, and if it can, no reason inn cant.

>
>> Thank you everyone for your help, I certainly learned a lot in this
>> past week, even if it turns out to be of no immediate use to us here,
>> it might be if I ever change jobs in an IPv6 only world.
>
> Good luck with your projects!  I am a bit sorry that INN did not fit
> your needs.  If only you had used the straight-forward adequate program
> (like xinetd) to fulfil your expectations on user tracking and limiting,
> you would have had a more pleasant experience!
>
as above, more pleasant, I dont think so with that many users, it
would be worse than imaginable. Oh and please dont say split the load
of more servers, again, if DNews can run so smoothly on one crappy
dl380g5 with 2 GB ram (with 35 TB DAS array), why would we waste
thousands more to run cluster of inn boxes, that would get me fired
:-)

PS your google foo must be far greater than mine, 99/100 hits ended up
beibg for  holiday inns, the upside to all that wasted googling was, I
know  have a new destination for my next holiday LOL

Nik
_______________________________________________
inn-workers mailing list
inn-workers@lists.isc.org
https://lists.isc.org/mailman/listinfo/inn-workers
[prev in list] [next in list] [prev in thread] [next in thread]