Re: [SR-Users] Kamailio Load Testing

the I use the exec() to run a shell script with the relevant mi command. the shell script return code is used to make sure all went OK. On Mon, Mar 26, 2012 at 14:56, Uri Shacked <ushacked at gmail.com<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users&… wrote: *>* *>* *>* *>* I made these kinds of tests before. I have two tips for you to pay *>* attention to: *>* *>* 1. Read about the [routes] on SIPp, It is tricky to satisfy kamailio *>* with SIPp scenarios. *>* *>* 2. Make sure your DB table is well build (use less varchars and more *>* integers). *>* *>* I found out that there are many kamailio modules I can use to load data in *>* to memory and I hardly use the DB (only for ACC). I use MTREE, HTABLE, *>* DIALPLAN, CARRIERROUTE, DROUTING, and so to store the information I need. *>* And I get it with the simple functions of the module. *>* *>* I load around 6 million numbers and other data which takes about 1.5 Gb of *>* the memory. *>* *>* For getting around the real-time changes that I need to deal with (In DB *>* the data changes are immediately made on your service…). I have a RTIMER *>* every 120 sec that check is a reload is needed. If so, it reloads the *>* relevant data (very fast). *>* *>* BR, *>* *>* Uri *>* *>* *>* *>* *>* Hello, *>* *>* On 3/20/12 12:12 PM, Stephen Dodge (Bistech) wrote: *>* >* *>* *>* Hello, *>* *>* *>* *>* I am running Kamailio 3.1.5 with a MySQL backend on CentOS. A *>* *>* connection to MySQL (an off box MySQL cluster) is required for every *>* *>* call, sqlops is used to determine destinations and acc to record CDR * *>* >* information. *>* *>* *>* *>* I am planning to load test our server using SIPp to generate calls, I *>* *>* was wondering if anyone has done something similar and could provide *>* *>* advice on what we should monitor on our Kamailio Server. i.e Server *>* *>* CPU & Memory *>* *>* *>* *>* Thanks in advance for your help. *>* *>* *>* *if you do a lot of direct DB interactions, perhaps latency of the *>* queries will be relevant. You can use benchmark module to see how long *>* it takes to execute part of the config file. *>* *>* I think you don't fetch lot of records from db in config, so memory *>* should be no problem, however you can dump private/shared memory usage *>* via RPC commands within sercmd cli. CPU is a good metric always and easy *>* to watch with systems tools. *>* *>* Cheers, *>* Daniel *>* >* *>* *>* Steve. *>* * *