<br>
With thousands of SIP clients each with a mailbox, voicemail code is
doing a ridiculous quatity of "SELECT COUNT(*) FROM %s WHERE dir=?" to
support MWI on each box.<br>
<br>
Not ridiculous in that voicemail needs to know how many messages each
box has, but just to point out that this can big a bottleneck with a
large number of subscribers. I don't see an easy fix. Maybe instead
of a thousand individual queries you can periodically -- say once every 20 sec -- scan the entire table, cache the results and do the
accounting in-memory. Or periodically do a "select count(*),dir,..
from %s GROPU BY dir" query.<br><br>Then have some caching optimizations so a user can get MWI notice as soon as a new message is left, in case you didn't want to wait up to 20 sec or whatever. That can get messy though. Ideally there's a model that would be relevant for IMAP and file
storage as well, already there are almost 3 implementations of
voicemail in app_voicemail.c.<br>
<br>
--Ryan<br>
<br><br><div><span class="gmail_quote">On 10/25/07, <b class="gmail_sendername">Tilghman Lesher</b> <<a href="mailto:tilghman@mail.jeffandtilghman.com">tilghman@mail.jeffandtilghman.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thursday 25 October 2007 06:06:37 Tobias Engel wrote:<br>> When there are about 100 parallel connections to asterisk (1.4.11, btw),<br>> all leaving voicemails, the peformance becomes really abysmal:<br>> Connections take over a minute before they are even accepted, etc.
<br>><br>> Since this does not happen when just using realtime for the voicemail<br>> config, but storing the messages itself on the local harddisk, I assumed<br>> some db (Oracle) or ODBC bottleneck (the CPU usage never goes over 20%).
<br>> But a few hundred added debug statements and some tcpdump sessions<br>> later, to my surprise I found out that most of the time is spent waiting<br>> for a lock on the "users" list in "find_user".
<br><br>We could probably fix this by switching over to using rwlocks.<br><br>> So far I couldn't find out why this only happens with ODBC message<br>> storage, but since this users list is - as far as I can see from the
<br>> source - unused when using realtime, do I even need this lock?<br><br>You do, to avoid a possible race condition with using the data versus<br>the data being destroyed on a reload.<br><br>> When the user data is fetched from the db, the operation should be
<br>> atomic - either it's there or it's not there, right?<br><br>It is, but the data transfer is not atomic -- it takes time to process each<br>column.<br><br>> So do you think it is safe to remove the AST_LIST_LOCK call for realtime
<br>> usage?<br><br>Definitely not. But as above, you could convert it to rwlocks. You'd just<br>have to make sure that there are no recursive locks, because rwlocks do<br>not support recursive locks.<br><br>> And does anybody have any insights on these performance issues? (I also
<br>> found out that it takes sometimes up to 6 seconds from the SQLExecute<br>> call in res_odbc until the call is really forwarded to the database -<br>> but I assume this is an ODBC issue)<br><br>It's probably another lock that is not exposed to the interface. You might
<br>post a note to the UnixODBC list, looking for an answer to that.<br><br>--<br>Tilghman<br><br>_______________________________________________<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">
http://www.api-digital.com--</a><br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev
</a><br></blockquote></div><br><br clear="all"><br>-- <br>Ryan Mitchell <<a href="mailto:rjm@tcl.net">rjm@tcl.net</a>><br>Telecom Logic, LLC<br><a href="http://www.tcl.net">http://www.tcl.net</a>
<br clear="all"><br>