[asterisk-users] When does Scalability requests Asterisk to U se SER ?

[adebayo omo-dare]

Hi Sheerwood, 
  I unfortunately saw a bit of what I percieve to be an error in what you said. BerkeleyDB does in fact support replication across nodes - see: http://www.sleepycat.com/docs/ref/rep/intro.html - possibly you meant to say the version implemented in * does not support replication. If so, I do appoligise for being a little pedantic.
   
  I have only just started to look at *'s code - so what I say further is with a great deal of hesitation when directly referenced to *. However, I work with both Berkely (on a programming level) and MySQL in a telecom (soft-switch) environment.
   
  In terms of performance (judged as speed), a comparison between MySQL and Berkeley would be like comparing a top of the range Mercedes to an F1 racing car. Overheads from MySQL come in the form of SQL translation, use of Sockets, etc... This is in addition to its size.
   
  Yet, the choice between the two, is a lot more complex, IMHO, than mereley thinking in terms of performance. And possible High Availability solutions, in their own rights, taking in to consideration that * will be working in concert with numerous other environments, programmes and requirments, are diverse enough to make each deployment a little unique - thereby making each option a potential liability.
   
  One rule of thumb for us has always been - if you need raw speed, and intend to deal with the data in a very restricted/rigid/"well defined" manner - opt for Berkeley. But if you want a great deal of fluidity, and intend, or may at some time intend, for that data to interact with other applications and potential requirements - Opt MySQL.
   
  It is possibly also best to work with what you feel most comfortable with first and then experiment to see if you may require the services of the other.
   
  ps. In terms of querying a DB for every call, I would presume that a DB is an active and fragile thing and the provision of ACID ensures that everything that occurs with it does so with a certain measure of safety. In fact, due to the random manner of requests, you will find it, in complete terms, actually performs a lot better than any other form of retrieval.
   
  Hope this, in some manner, helps
  Bayo
  
Rushowr <rushowr at phreaker.net> wrote:
  > good stuff mate.
> 
> a few clarifications:
> you had static "extensions.conf", realtime "sipusers", etc, right?
> 
> Also, abt features like call fwding, etc, which one is better,
> performance wise, using a mysql db, or use Asterisk's internal
> DB(berkeley db, isnt it?using those DBput n DBget ops)??Anyone's got any
> figures for these?
> 
> This somewot spoils the fun in Asterisk, when talking of performance, to
> query the DB for every call . Sort of pulls things down. Any comments or
> observations guys?
> 
> - Ben.

Ben,

Yes, static extensions.conf, realtime everything else. A realtime
dialplan never made much sense to me, as the dialplan shouldn't (in my
humble opinion) be that fluid anyway, it should be fairly static.

In terms of spoiling the fun and/or performance issues, let me note that
in my current implementation we not only have options being queried but
also realtime billing, permissions, limits, and carrier/trunk
performance data, all being pulled and calculated via the database. I
also have handy little timers returning the length of time it takes to
do the processing from request receipt to dial, and I'm still currently
under 1-2 seconds for entire call preparation including all the logic
that goes along with checking all features, the current account's
account status, balance and limits, AND all parent accounts in it's
"billing chain". I haven't done a head to head with the berkley DB, but
I think part of the reason it's so fast is due to the highly normalized
database structure, which allows for efficient query design. It's not
all third form, but almost there :D.

I'm in the last days of ALPHA now with my current project. Once we
launch BETA, which will be a semi-public testing by invitation (Murph,
you still going to participate?), I should be able to find a few minutes
to outline the design.

One other quick thing, the berkley DB doesn't allow for clustering
either, MySQL does. Very nice to have your database distributed across
multiple nodes, makes for an easier time designing the failovers :D

Cheers,
Sherwood

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users


 		
---------------------------------
 Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060920/555069c8/attachment.htm