[asterisk-dev] voicemail: AST_LIST_LOCK in find_user necessary when using realtime?

[Tilghman Lesher]

On Thursday 25 October 2007 06:06:37 Tobias Engel wrote:
> When there are about 100 parallel connections to asterisk (1.4.11, btw),
> all leaving voicemails, the peformance becomes really abysmal:
> Connections take over a minute before they are even accepted, etc.
>
> Since this does not happen when just using realtime for the voicemail
> config, but storing the messages itself on the local harddisk, I assumed
> some db (Oracle) or ODBC bottleneck (the CPU usage never goes over 20%).
> But a few hundred added debug statements and some tcpdump sessions
> later, to my surprise I found out that most of the time is spent waiting
> for a lock on the "users" list in "find_user".

We could probably fix this by switching over to using rwlocks.

> So far I couldn't find out why this only happens with ODBC message
> storage, but since this users list is - as far as I can see from the
> source - unused when using realtime, do I even need this lock?

You do, to avoid a possible race condition with using the data versus
the data being destroyed on a reload.

> When the user data is fetched from the db, the operation should be
> atomic - either it's there or it's not there, right?

It is, but the data transfer is not atomic -- it takes time to process each
column.

> So do you think it is safe to remove the AST_LIST_LOCK call for realtime
> usage?

Definitely not.  But as above, you could convert it to rwlocks.  You'd just
have to make sure that there are no recursive locks, because rwlocks do
not support recursive locks.

> And does anybody have any insights on these performance issues? (I also
> found out that it takes sometimes up to 6 seconds from the SQLExecute
> call in res_odbc until the call is really forwarded to the database -
> but I assume this is an ODBC issue)

It's probably another lock that is not exposed to the interface.  You might
post a note to the UnixODBC list, looking for an answer to that.

-- 
Tilghman