<DIV>Hi Sheerwood, </DIV>  <DIV>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: <A href="http://www.sleepycat.com/docs/ref/rep/intro.html">http://www.sleepycat.com/docs/ref/rep/intro.html</A>&nbsp;- possibly you meant to say the version implemented in * does not support replication. If so, I do appoligise for being&nbsp;a little pedantic.</DIV>  <DIV>&nbsp;</DIV>  <DIV>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)&nbsp;and MySQL in a telecom (soft-switch) environment.</DIV>  <DIV>&nbsp;</DIV>  <DIV>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.</DIV>  <DIV>&nbsp;</DIV>  <DIV>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&nbsp;in concert with numerous other&nbsp;environments,&nbsp;programmes and requirments,&nbsp;are diverse enough to make each deployment a little unique - thereby making each option a potential liability.</DIV>  <DIV>&nbsp;</DIV>  <DIV>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"&nbsp;manner - opt for Berkeley. But if you want a great deal of fluidity, and intend, or may at some time intend,&nbsp;for that data to interact with other applications and potential requirements -&nbsp;Opt MySQL.</DIV>  <DIV>&nbsp;</DIV>  <DIV>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.</DIV>  <DIV>&nbsp;</DIV>  <DIV>ps. In terms of querying a DB for every call, I would presume that a DB is an active and fragile&nbsp;thing and the provision of ACID ensures that everything that occurs with it does so&nbsp;with a certain measure of safety. In fact, due to the random manner of requests, you will find it, in complete terms,&nbsp;actually performs a lot better than any other form of retrieval.</DIV>  <DIV>&nbsp;</DIV>  <DIV>Hope this, in some manner,&nbsp;helps</DIV>  <DIV>Bayo</DIV>  <DIV><BR><B><I>Rushowr &lt;rushowr@phreaker.net&gt;</I></B> wrote:</DIV>  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">&gt; good stuff mate.<BR>&gt; <BR>&gt; a few clarifications:<BR>&gt; you had static "extensions.conf", realtime "sipusers", etc, right?<BR>&gt; <BR>&gt; Also, abt features like call fwding, etc, which one is better,<BR>&gt; performance
 wise, using a mysql db, or use Asterisk's internal<BR>&gt; DB(berkeley db, isnt it?using those DBput n DBget ops)??Anyone's got any<BR>&gt; figures for these?<BR>&gt; <BR>&gt; This somewot spoils the fun in Asterisk, when talking of performance, to<BR>&gt; query the DB for every call . Sort of pulls things down. Any comments or<BR>&gt; observations guys?<BR>&gt; <BR>&gt; - Ben.<BR><BR>Ben,<BR><BR>Yes, static extensions.conf, realtime everything else. A realtime<BR>dialplan never made much sense to me, as the dialplan shouldn't (in my<BR>humble opinion) be that fluid anyway, it should be fairly static.<BR><BR>In terms of spoiling the fun and/or performance issues, let me note that<BR>in my current implementation we not only have options being queried but<BR>also realtime billing, permissions, limits, and carrier/trunk<BR>performance data, all being pulled and calculated via the database. I<BR>also have handy little timers returning the length of time it takes to<BR>do the
 processing from request receipt to dial, and I'm still currently<BR>under 1-2 seconds for entire call preparation including all the logic<BR>that goes along with checking all features, the current account's<BR>account status, balance and limits, AND all parent accounts in it's<BR>"billing chain". I haven't done a head to head with the berkley DB, but<BR>I think part of the reason it's so fast is due to the highly normalized<BR>database structure, which allows for efficient query design. It's not<BR>all third form, but almost there :D.<BR><BR>I'm in the last days of ALPHA now with my current project. Once we<BR>launch BETA, which will be a semi-public testing by invitation (Murph,<BR>you still going to participate?), I should be able to find a few minutes<BR>to outline the design.<BR><BR>One other quick thing, the berkley DB doesn't allow for clustering<BR>either, MySQL does. Very nice to have your database distributed across<BR>multiple nodes, makes for an easier time
 designing the failovers :D<BR><BR>Cheers,<BR>Sherwood<BR><BR>_______________________________________________<BR>--Bandwidth and Colocation provided by Easynews.com --<BR><BR>asterisk-users mailing list<BR>To UNSUBSCRIBE or update options visit:<BR>http://lists.digium.com/mailman/listinfo/asterisk-users<BR></BLOCKQUOTE><BR><p>&#32;
                <hr size=1> 
Now you can <a href="http://us.rd.yahoo.com/mail/uk/taglines/default/nowyoucan/reading_pane/*http://us.rd.yahoo.com/evt=40565/*http://uk.docs.yahoo.com/nowyoucan.html">scan emails quickly with a reading pane</a>. Get the new <a href="http://us.rd.yahoo.com/mail/uk/taglines/default/nowyoucan/reading_pane/*http://us.rd.yahoo.com/evt=40565/*http://uk.docs.yahoo.com/nowyoucan.html">Yahoo! Mail</a>.