[Serusers] Usrloc performance

[Teemu Harju]

Ok, I changed the order of the users registering to the system to random and
now after all users are registered the load of the system stays constant,
like it should. Thanks to Michael for pointing this out to me. I haven't yet
increased the hash table size, although it would be interesting to see if I
could gain some perfomance that way.

- Teemu

2006/3/10, Teemu Harju <teemu.harju at gmail.com>:
>
> Hi, Michael
>
> You're right. Why didn't I think of that. :)
>
> I also got instructions from OpenSER mailing list to increase the size of
> the hash table by modifying the source of the usrloc, since I'm using so
> many users.
>
> Thanks for your comments. I'll report back what were the results with
> these modifications.
>
> - Teemu
>
> 2006/3/10, Michal Matyska < michal at iptel.org>:
> >
> > This seems to me quite understandable, the time is consumed while
> > locating the
> > usrloc entry. Try to change the "SEQUENTIAL" order to "RANDOM" in the
> > SIPP injection file, I suppose you'd then get what you expected, equal
> > CPU
> > usage during all the time the test runs. If not, please post it again.
> >
> > Michal
> >
> >
> > On Fri, Mar 10, 2006 at 09:57:36AM +0200, Teemu Harju wrote:
> > > Hi!
> > >
> > > I posted about this same subject to openser mailing list already, but
> > since
> > > I haven't had response from there I'll try here. I guess the usrloc
> > module
> > > and the core functionality is quite the same with ser and openser.
> > >
> > > I've been running some performance tests on my OpenSER box and while
> > > registering large number of users I faced some very strange problems.
> > At
> > > least they seem strange to me, but I hope someone on this list would
> > be able
> > > to shed some light on this.
> > >
> > > So, I use Openser 1.0.1 and I load test it using SIPp. I've done tests
> > > creating about 1000 registrations per second registering 300k-450k
> > different
> > > users. Register rate is constat and for each register different user
> > is
> > > used. What is strange to me that just about when 300k users have
> > registered
> > > the CPU of the PC running the proxy hits 100% usage and messages start
> > > dropping. I made a nice image to illustrate my problem using Excel.
> > Check it
> > > at http://www.teemuharju.net/wp-images/register_300k_users_at_1000rps.png
> > .
> > >
> > > On this test I registered 300k different users at 1000 RPS and after
> > > registering those users the registering starts again from the
> > beginning. As
> > > you can see from it the CPU usage rises constantly and drops
> > immediately
> > > after I've registered 300k users and the registering starts again from
> > the
> > > start. So then each user is being registered all over again, but still
> > the
> > > CPU load grows. Does anyone have explanation for this? Why does the
> > CPU
> > > usage grow based on the number of users registered? And why does it
> > drop for
> > > a while when registering starts all over again? I've tried different
> > usrloc
> > > modes, but there seems to be no difference. This one was done with
> > having
> > > usrloc only in the memory. Shouldn't the CPU usage at constant
> > register
> > > rate, be somewhat constant also? Has anyone else noticed the same
> > problem?
> > > Could this be somehow explained or do I have something wrong with my
> > system?
> > >
> > > Regards,
> > >
> > > Teemu
> > >
> > > --
> > > Teemu Harju
> > > http://www.teemuharju.net
> >
> > > _______________________________________________
> > > Serusers mailing list
> > > serusers at lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> >
>
>
>
> --
> Teemu Harju
> http://www.teemuharju.net
>



--
Teemu Harju
http://www.teemuharju.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060310/4175e37f/attachment.htm>