Re: Putting Load on GnuGK Full Proxy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I am currently using FileAcct on my GnuGK.
Want to use SQL accounting.  What is recommended? MySQL or PostgreSQL?
I'm familiar with both, but would like your ideas / tips / insights.
Is it ok to use the DB Server on the same machine as the GnuGK?

Regards
HASSAAN



----- Original Message ----- 
From: "Nyamul Hassaan" <mnhassan@xxxxxxx>
To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, October 10, 2005 22:24
Subject: Re:  Putting Load on GnuGK Full Proxy


> Thx Frank for sharing your experience.
> And, thx Michal for giving us insights from the developers.
>
> However, I still am confused with the RAM issue.
> Even under 40-50 calls load, my GnuGK shows only 170MB loaded.
> Is this normal?
>
> I'm monitoring the system, and have found the processor is 35-40% utilized
> on a single PIV 2.4GHz.
> I'm moving to a Dual Xeon over the weekend.  Will let you know how that
> goes.
>
> Regards
> HASSAAN
>
>
>
> ----- Original Message ----- 
> From: "Zygmuntowicz Michal" <m.zygmuntowicz@xxxxxxx>
> To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx>
> Sent: Monday, October 10, 2005 15:13
> Subject: Re:  Putting Load on GnuGK Full Proxy
>
>
> > One side note about H.245 tunneling. I'd recommend
> > either to have all traffic with H.245 tunneling enabled
> > or disable H245Routed flag, as the gatekeeper does not
> > handle well all cases when a separate H.245 TCP channel
> > is being used.
> >
> > I think performance is comparable for small call volumes
> > (let's say 100-200) on both Windows and Unixes. For large
> > call volumes, Unixes have their advantages. Of course, these are
> > not limits of Windows OS itself, rather than socket handling techniques
> > implemented in the gatekeeper.
> >
> > ----- Original Message ----- 
> > From: "Frank Fischer" <frank.fischer@xxxxxxxxxxxxxxxx>
> > Sent: Monday, October 10, 2005 3:06 AM
> >
> >
> > > [<nh>] I am trying to put some load on GnuGK and see how it performs.
> It is
> > > a totally amazing experience.  Watching the status window seems a lot
> > > similar to the numbers dropping in the movie Matrix.
> > >
> > > [<fi> ] Just for my information: What callgeni are you using? Dou you
> only
> > > test call signaling capacity or also voice quality? I'm very
interested
> to
> > > learn more about you test setup.
> > >
> > > [<nh>] CallGenI?  Do you mean CallGenerator? No, I'm not using any
call
> > > generator.  I'm using this box LIVE in route, as a simple SS
> (FileIPAuth, no
> > > other Authentication) between my buyers and my terminators.  That is
why
> I
> > > faced the nightmare today, when I added some capacity in the
termination
> > > side, but increased the wrong IP's entry in the INI file (the wrong
one
> was
> > > just 1 digit off).  :))  Took me around 3-4 minutes to figure out, but
> in
> > > those 3-4 minutes it felt as if my existence was at stake!!!
> > > [<fi> ] Ah, i see. Nothing better than letting your customers test
your
> > > softswitch :-)
> > >
> > > [<nh>] I'm running GnuGK Full Proxy & FileIPAuth on Win2003 with a PIV
> > > 2.4GHz 1024MB RAM system.  I've had no problems running 30-32
> simultaneous
> > > calls.  I'm now testing with 40-50 calls, and faced the "Too Many
Ports"
> > > error, which was corrected by increasing the CallSignalHandler and
> > > RtpHandler to 3 each.  Having a problem like this on a live system is
> just
> > > like your worst nightmare.
> > > [<fi> ] If you run into port limitations, you may also use h.245
> tunneling
> > > to "save" some ports per call.
> > > [<nh>] Thanks for the tip.  Does that increase overhead?
> > > [<fi> ] I don't think so. But Jan or Michal sure no better.
> > > Any performance bumps?
> > > [<fi> ] Same
> > > Any ideas on what impact CallSignalHandler and RtpHandler has on
> processor /
> > > memory usage?
> > > [<fi> ] As far as we tested, none in special. Of course usage will
grow
> > > because of increasing traffic (but that's why you are raising the
> handlers).
> > > There is a presentation of the open telephony summit on the gnugk
> website
> > > where Jan put it a rule of thumb to calculate how many handlers one
> should
> > > use depending on the traffic expected.
> > >
> > > [<nh>] Currently, my CPU is showing a 40-45% load. And, my memory
> > > utilization is at 150MB.  My Bandwidth Utilization is around 1.2-1.4
> Mbps
> > > (G.723r63 codec only), as shown by DUMeter.
> > >
> > > [<nh>] I have learned a few things during all this:
> > >
> > > [<nh>] 1.  It's best to turn debugging off, when no debugging info is
> > > needed.  That makes the CPU load lower, and GnuGK more responsive.
> > >
> > > [<fi> ] Yes, that's my experience too. It doesn't take much on debug
trc
> 5
> > > to generate lag on the call signaling.
> > >
> > > [<nh>] 2.  When doing changes to the INI File, (Re)^n check your
config
> > > file, for even the smallest of changes.  A small mistake can be fatal.
> > >
> > > [<nh>] Now, here are my questions:
> > >
> > > [<nh>] 1.  Is 40-45% load alright for my GnuGK to perform smoothly?
> What
> > > should be the ideal range?
> > > [<nh>] 2.  Will GnuGK be able to handle more / less calls if =>
> > > [<nh>] 2 a.  Proxy is set to 0?
> > >
> > > [<fi> ] Yes.  Diff: Factors.
> > > [<nh>] Could you mention the factors?
> > > [<fi> ] Hard to say. But sure at least three or four times more, i
would
> > > expect even more.
> > > I have ample BW (3Mbps), so BW is not an issue.  Would port count be
> > > reduced of Proxy is set to 0 (probably RTP ports wont be needed?)?
> > > [<fi> ] Sure. I would only use proxy if you really need it.
> > > What other factors?
> > >
> > > [<nh>] 2 b.  OS is changed to Linux or FreeBSD or anything else?
> > > [<fi> ] Linux yes (others i don't know). Diff: Some 10 percents more
in
> best
> > > case.
> > >
> > > [<nh>] Did you actually test on different OSes?  I remember someone
> > > (probably Michal) mentioning that Linux uses ports more efficiently.
> > > [<fi> ] We tested on Linux (fc3) and W2k03 SRV. Regarding ports
handling
> > > there are "strange" issues on both OSes.
> > >
> > >
> > > [<nh>] 2 c.  I reduce RAM to 512 MB or even 256MB, since only 150 out
of
> > > 1024 MB is shown by Windows as used?
> > > [<fi> ]  On Windows, do not remove RAM, better think of adding add.
RAM
> and
> > > disably swap file. Also, a fast mainbord and RAM can increase
> performance by
> > > some 10 percent easily.
> > > [<nh>] Disable swap file?  What will that do?
> > > [<fi> ] Prevent windows from permanently swapping ram to harddisk and
> vice
> > > versa. The swapping process slows almost everything down.
> > > As I said, my Mem Utilization is at only 15% max.  Would you still
> suggest
> > > adding more RAM?
> > > [<fi> ] Yes (of course always depending on how much traffic you will
> have on
> > > your system). But: best thing to do is to monitor your system and when
> you
> > > find out that ressources are getting low or you realize service
quality
> > > problems, you still have time to react.
> > >
> > >
> > > [<nh>] => In all these 3 cases, how much difference in performance can
I
> > > expect?
> > >
> > > [<fi> ]  Please understand that i can only make an estimation based on
> my
> > > testing experience.
> > > [<nh>] Yes, I was looking for sharing my experiences among GnuGKusers.
> > >
> > > [<fi> ]  One more point about testing: if you reach limits, carefully
> check
> > > if it are gatekeeper limits or callgeni limits!
> > > [<nh>]  As I said, I was checking with live Traffic, and the GnuGK was
> > > accepting calls from 2 different IPs (via FileIPAuth), each of which
> were
> > > Cisco5350.  And, they hit calls really fast, e.g., during those 3-4
> minutes,
> > > when I had the wrong entry, I had around 10-15 call requests hitting
> every
> > > sec for a mere 5 ch increase in capacity.
> > >
> > > [<nh>]  One other question, if I run multiple instances of GnuGK bound
> to
> > > different IPs on the same machine, will it be reducing the total Max
> Call
> > > Handling Capability count?  Say on the same Machine, I have the
> following
> > > setup:
> > > 1.  GnuGKX handling only Call Signalling (with FileIPAuth only), with
> Proxy
> > > set to 0.  This only routes the calls to other GnuGKs on the same
> machine.
> > > 2.  GnuGK1...n (1<n<10), all running on Proxy=1, and having FileIPAuth
> on
> > > each to accept from only GnuGKX.
> > > Will this scenario reduce the total Max Call Capability of the whole
> BOX?
> > > [<fi> ] No idea. I have never done this and to be honest, i don't
think
> that
> > > i will ever try this since i don't think it's a good idea to have
> multiple
> > > instances of a gatekeeper on one machine (as with many other services
> too).
> > > If you can do it with one gatekeeper instance, i would do it with one.
> > > Generally multiple instances of any service produce overhead and
> ressource
> > > conflicts (espacially if they were not implemented with multiple
> instances
> > > in mind).
> > > But maybe some on the list has done this before?
> > >
> > > Regards
> > > Frank
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads,
discussions,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________________
> >
> > Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
> > Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
> > Unsubscribe:
http://lists.sourceforge.net/lists/listinfo/openh323gk-users
> > Homepage: http://www.gnugk.org/
> >
>



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/

[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux