9 Mar
2009
9 Mar
'09
8:19 p.m.
I have spec'd out how my LCR table would look based my current PSTN
gateway providers. Looks like I would need to load roughly 300,000
routes to properly represent everything.
This server needs to be able to support spikes of 100 call setups per second.
What is the general consensus on this? And, if it's a No-Go, what
alternatives do I have? I have looked briefly at the CarrierRoute
module, but haven't actually played with it.
Thanks!
Geoff
9 Mar
9 Mar
8:25 p.m.
Carrierroute is able to handle this.
The new lcr (1.5) should be able to handle this. Make sure that you
use a big hash table:
http://www.kamailio.net/docs/modules/1.5.x/lcr#id2492264
In both cases, avoid realtime db lookups if you want to be able to
handle spikes of 100cps.
Regards,
Ovidiu Sas
On Mon, Mar 9, 2009 at 2:19 PM, Geoffrey Mina <geoffreymina(a)gmail.com> wrote:
I have spec'd out how my LCR table would look
based my current PSTN
gateway providers. Looks like I would need to load roughly 300,000
routes to properly represent everything.
This server needs to be able to support spikes of 100 call setups per second.
What is the general consensus on this? And, if it's a No-Go, what
alternatives do I have? I have looked briefly at the CarrierRoute
module, but haven't actually played with it.
Thanks!
Geoff
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
8:39 p.m.
Thanks for your answer.
I am using 1.5, so that's a good start!
In regards to preventing real time DB lookups... If I set my hash size
to 640K, and I have 300K records in my routes table I will never need
to do a real time DB lookup? How important is it to match the size of
the hashtable with the size of your routes table? Will too much space
cause inefficiency? I assume too little space would cause db lookups?
I have 8G of RAM available on this machine, so I am not concerned with
storing a lot of information in memory.
Thanks,
Geoff
On Mon, Mar 9, 2009 at 2:25 PM, Ovidiu Sas <osas(a)voipembedded.com> wrote:
Carrierroute is able to handle this.
The new lcr (1.5) should be able to handle this. Make sure that you
use a big hash table:
http://www.kamailio.net/docs/modules/1.5.x/lcr#id2492264
In both cases, avoid realtime db lookups if you want to be able to
handle spikes of 100cps.
Regards,
Ovidiu Sas
On Mon, Mar 9, 2009 at 2:19 PM, Geoffrey Mina <geoffreymina(a)gmail.com> wrote:
I have spec'd out how my LCR table would look
based my current PSTN
gateway providers. Looks like I would need to load roughly 300,000
routes to properly represent everything.
This server needs to be able to support spikes of 100 call setups per second.
What is the general consensus on this? And, if it's a No-Go, what
alternatives do I have? I have looked briefly at the CarrierRoute
module, but haven't actually played with it.
Thanks!
Geoff
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
8:53 p.m.
Both carrierroute and lcr are loading the routes into memory during
start-up, so there will be no db issues here.
Try to avoid avpops and sqlops in your script (this is what I meant by
avoiding db lookups). If you need to do some lookups, use the htable
module.
If you match the size of the hash table with the size of your routes,
there will be faster searches and better performances for your lcr
routing.
Regards,
Ovidiu Sas
On Mon, Mar 9, 2009 at 2:39 PM, Geoffrey Mina <geoffreymina(a)gmail.com> wrote:
Thanks for your answer.
I am using 1.5, so that's a good start!
In regards to preventing real time DB lookups... If I set my hash size
to 640K, and I have 300K records in my routes table I will never need
to do a real time DB lookup? How important is it to match the size of
the hashtable with the size of your routes table? Will too much space
cause inefficiency? I assume too little space would cause db lookups?
I have 8G of RAM available on this machine, so I am not concerned with
storing a lot of information in memory.
Thanks,
Geoff
On Mon, Mar 9, 2009 at 2:25 PM, Ovidiu Sas <osas(a)voipembedded.com> wrote:
Carrierroute is able to handle this.
The new lcr (1.5) should be able to handle this. Make sure that you
use a big hash table:
http://www.kamailio.net/docs/modules/1.5.x/lcr#id2492264
In both cases, avoid realtime db lookups if you want to be able to
handle spikes of 100cps.
Regards,
Ovidiu Sas
On Mon, Mar 9, 2009 at 2:19 PM, Geoffrey Mina <geoffreymina(a)gmail.com> wrote:
I have spec'd out how my LCR table would look
based my current PSTN
gateway providers. Looks like I would need to load roughly 300,000
routes to properly represent everything.
This server needs to be able to support spikes of 100 call setups per second.
What is the general consensus on this? And, if it's a No-Go, what
alternatives do I have? I have looked briefly at the CarrierRoute
module, but haven't actually played with it.
Thanks!
Geoff
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
10 Mar
10 Mar
6:54 p.m.
On Monday 09 March 2009, Geoffrey Mina wrote:
I have spec'd out how my LCR table would look
based my current PSTN
gateway providers. Looks like I would need to load roughly 300,000
routes to properly represent everything.
This server needs to be able to support spikes of 100 call setups per
second.
What is the general consensus on this? And, if it's a No-Go, what
alternatives do I have? I have looked briefly at the CarrierRoute
module, but haven't actually played with it.
Hi Geoffrey,
i did some tests with cr with this size of the routing tree, there are also
some people that uses it with even more routes. Make sure that you increase
the shared memory size (should be not a problem with today memory sizes) a
bit, and use a 1.4.x or 1.5.x release. Then it should run just fine. I can't
really comment on the LCR module, did not used it after the refactoring for
1.5.0.
Cheers,
Henning
5737
days inactive
5738
days old
4 comments
3 participants
participants (3)
-
Geoffrey Mina -
Henning Westerholt -
Ovidiu Sas