[Asterisk-Dev] Performance bottleneck in voicemail2 on nfsed huge mailboxes

[Levent Guendogdu]

On Sun, 2003-09-28 at 05:17, asterisk at billheckel.com wrote:
> There has been a long standing design flaw in voicemail that I have mentioned repeatedly.  If you 
> are listening to your voicemail and another voicemail comes in it ends up orphaned until you get at 
> least that many voicemails in your box.  I had looked into a simple patch to fix this before but it 
> requires a fairly serious redesign of the numbering scheme.  All voicemail should have a unique ID 
> that is globally unique and time based ( like unix milliseconds ) so that incoming voicemail is 
> always in order.
> 
> If each mail is named using this and the voicemail listening section checks for the total number of 
> existant files it will work but there is a bit of work to be done.  I had started to rewrite this 
> but when voicemail2 was announced I assumed it would be corrected.

I know. I have been looking into the code a lot yesterday. Just
"changing the filenames" isn't as easy as I thought it to be. As you
say, it would result in an almost complete rewrite of voicemail. The msg
number is being used in almost any corner of the voicemail application
in a call to make_file(). So anytime a message is accessed, it uses the
message's number to generate a file name which it accesses. The message
number is also used for "navigating" the voicemails.

As far as I can see, this behaviour is both in voicemail and voicemail2.

So, the first step, would be to redesign that beast. First and the most
important thing: Storage (re-)design. A database based approach would
certainly be interesting,  but I (personally ;) want * to remain
operational without mysql. I thought of some sort of front-/back-end
design like CDR. If we could abstract the voicemail storage, we could
have different backends (mysql, file, etc.) for storing the mails and
the voicemail apps (frontends) just access those storages. 

So, defining the storage interface is up first, IMHO. What do you people
think?

BTW, my first idea of storing the voicemail in a temporary directory and
copying the message to the box afterwards would certainly work to
overcome my "two seconds loss"-problem, but there is an unpleasant side
effect: the copy would stress the * box by maxing out I/O. When *
records voicemail, it distributes it to n formats simultaneously which
results in minimal i/o at a time.  So copying the voicemails afterwards
isn't a solution. For now, I have patched voicemail2 to emit a beep when
it is really ready to start recording (after it has chosen the
filename), not before.  But this is a very dirty solution.

Bye,
 Lev.


> Bill
> 
> 
> Steven Critchfield wrote:
> > On Sat, 2003-09-27 at 10:33, Levent Guendogdu wrote:
> > 
> >>... another "workaround" just popped into my mind, which would be
> >>simpler to implement IMHO:
> >>
> >>after playing the beep, record the voicemail audio to a (some) tmp
> >>file(s), like 
> >>
> >>/tmp/<currentsystemtime>.gsm
> >>
> >>After hangup, look for the next msg num and save the meta file and
> >>voicemail.
> >>
> >>Sounds good to me for a first step, if no one objects, I'll patch this.
> > 
> > 
> > Or a more scalable method that would also help out for a project that
> > Tilghman needs, just name the messages with the epoch of creation and
> > maybe a md5 of the caller id. This would let you create the filename in
> > a method that is sortable and pretty much guaranteed to be unique
> > without consulting the filesystem first. This also should make the
> > filenames unique enough to bounce from mailbox to mailbox without
> > renaming. Also you could delete a message and still have the gap filled.
> > BTW, if MySQL is the answer than you probably are asking the wrong
> > question.
> > 
> > 
> >>On Sat, 2003-09-27 at 17:20, Levent Guendogdu wrote:
> >>
> >>>Hi all,
> >>>
> >>>there is a performance bottleneck in the voicemail2 code where it
> >>>determines the next message number for the voicemail by checking for
> >>>filename existance. On my K6/400 * box, which serves only a few
> >>>mailboxes, this takes up to two seconds. So, logically, because this
> >>>occurs after the BEEP has already been played to the caller, the first
> >>>two seconds of the message are being dropped.
> >>>
> >>>I've seen the addition of mysql support in voicemail2. How about storing
> >>>the currenct msg num in mysql, too? 
> >>>
> >>>Or adding some sort of index file for a mail box which contains the last
> >>>msg num.
> >>>
> >>>I see that, if you delete message in between, the current code would
> >>>simply "fill the gap" by numbering the next incoming voicemail to the
> >>>"first free" one. 
> >>>
> >>>To bring both worlds together I'd suggest switching to a voicemail
> >>>message id instead of msg num.
> >>>
> >>>What do you people think?
> >>>
> >>>Levon.
> >>>
> >>>_______________________________________________
> >>>Asterisk-Dev mailing list
> >>>Asterisk-Dev at lists.digium.com
> >>>http://lists.digium.com/mailman/listinfo/asterisk-dev
> >>
> >>_______________________________________________
> >>Asterisk-Dev mailing list
> >>Asterisk-Dev at lists.digium.com
> >>http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev