[Asterisk-Users] CDR Output

Tilghman Lesher tilghman at mail.jeffandtilghman.com
Wed Mar 5 10:32:56 MST 2003


Actually, I think you'll find that it's easier to manage and plan
for database usage than it is to recover from unexpected database
load.  It really doesn't matter what database you're using; even
the most heavy-duty mainframe will underperform if you get
unexpected traffic.

On Wednesday 05 March 2003 10:29, Chris Albertson wrote:
> Would it just be easier to use a database system that managed
> concurent access better?  Most all of them don't have trouble
> with this and don't require work-arounds like hot copies and
> so on.
>
> --- asterisk at billheckel.com wrote:
> > I am always wary of allowing ad-hoc queries that may lock
> > tables on a production system.  One
> > relatively easy way to avoid this issue is to use hotcopy to
> > make a read-only reporting database
> > that gets updated every x minutes.  The other is to use
> > replication if you need an up to the second
> > copy.
> >
> > Bill
> >
> > Chris Albertson wrote:
> > > I tested both MySQL and PostgreSQL under various loads,
> > > Actually got paid to do it.  In the simple case where one
> > > process just stuffs data into the database with INSERT
> > > MySQL was about 4x faster in terms of INSERT/second
> > >
> > > However if you have five or six processes that are doing
> > > lots of transactions, mixed INSERT and SELECT, MySQL
> > > grinds to a halt The trouble is locking.  MySQL only lets
> > > one process at a table at
> >
> > a
> >
> > > time so everyone else is shut out waiting.
> > >
> > > On a large PBX with high call volume you can't afford to
> > > have a table locked for 10 or 30 seconds while some guy
> > > does an ad-hoc join.
> > >
> > > PostgreSQL is more stable but can "only" do a few hundred
> > > INSERT per second on PC hardware vs. well over 1000/sec
> > > for MySQL.
> > >




More information about the asterisk-users mailing list