[asterisk-dev] [Code Review] Rate limit astdb->sync() calls

[Russell Bryant]

----- Original Message -----
> Hi,
> 
> >> +1 for that! While I don't fully understand all the technical
> >> discussions going on about astdb, it would be great to see Stefan's
> >> release the code for his testing tool. I would be very interested
> >> in
> >> seeing how it works.
> >
> > While the most recent results have been specific to astdb, the more
> > important numbers are the effects on SIP registration performance as
> > a result of the changes. That's how we got into astdb, since it was
> > identified as one of the bottlenecks when doing SIP registration
> > load testing. I'm not sure how Stefan's test is built, but doing
> > that via SIPp is pretty easy (at least as far as SIPp goes).
> >
> 
> I don't quite understand the low level implementation of this, though
> there is something that could be worth mentioning.
> 
> In other software I've been using, such as OpenSIPS and Kamailio,
> different strategies are provided for saving information such as
> registrations:
> - Memory-only storage, thus no persistent storage and everything is
> lost on restart
> - Write-back approach: information is stored in memory and synced at
> regular intervals. Data loss might happen if the software is restarted
> before data is synced but in some cases this could be affordable.
> - Write-through approach: data is synced to persistent storage every
> time. This has worse performance, but data loss is prevented.
> 
> Again, I might be missing something, but does this model make sense
> here?

This does make perfect sense.  We could also go this route.

The existing behavior for Asterisk is the write-through approach.  It has pretty much always been that way.  It writes to astdb (a db1 database on disk) and syncs using fsync().

The patch I've posted is sort of like the write-back approach, but not exactly.  Every registration is still being written to the database (write()), but the fsync() is no longer done every time.

We could extend this to make the various types of behavior optional if someone wants to.  I probably won't do it, though.  :-)

--
Russell Bryant
Digium, Inc.  |  Engineering Manager, Open Source Software
445 Jan Davis Drive NW   -    Huntsville, AL 35806  -  USA
jabber: rbryant at digium.com    -=-    skype: russell-bryant
www.digium.com -=- www.asterisk.org -=- blogs.asterisk.org