[asterisk-dev] RealTime, Large Dialplans, and headaches... got any ideas?

[Steve Murphy]

On Tue, 2007-03-27 at 14:35 -0600, Steve Murphy wrote:
> OK, I just closed 9037 after a conversation with kpfleming.
> Here is the situation:
> 
> 9037's reporter is complaining that with a large dialplan, in order to
> look up an extension, and do the pattern matching, asterisk pulls every
> extension from the context in the DB, and tries to find the best match.
> When the dialplan gets big, and you have hundreds/thousands (or more) of
> extensions, then this takes a while. The user was reporting 5 or more
> seconds.
> 
> I've been working on a search-tree algorithm that would find an
> extension match a bit faster in a large dialplan. It's speed is a
> function of the length of the patterns, not of how many extensions there
> are. I thought I might apply this to the RT extensions, and keep an
> in-mem copy of the search tree... but it depends on a lot of things,
> like being able to discern an update to the DB of the dialplan, so you
> can reform (or spot edit, which I believe is possible) the in-mem search
> tree.
> 
> Kevin pointed out:
> 
>         This is impossible because you have no way of knowing when the
>         database
>         is modified. Even if you did, you'd have to resort to rebuilding
>         the
>         'search tree' in memory, and if the dialplan is large enough
>         then the
>         other issue comes into the picture as well.
>         
>         This is an artifact of the way the Realtime system is
>         architected, which
>         means that it is broken. It is not fixable in the current
>         architecture.
> 
> If someone in the community has a brilliant flash of inspiration as to
> how this problem could be solved, we'd love to hear about it! Any ideas?
> 
> murf

Perhaps this comment isn't so much a bright idea as to how to attack in
the current architecture, as much as what the requirements would have to
be in a future architecture...

As I see it, wouldn't it be best to allow the user to have
extension_delete,
extension_add functions to accomplish adding, removing, (and changing)
an extension entry in the db... as a minimum. Maybe these funcs don't
even affect the DB, just the search tree. If you don't use them, it's
life as normal, the slow linear search. If you do use them, you get
faster searches...? It looks like
you still have the contexts in the extensions.conf, with a 'switch' to
direct you the DB; and the search trees are on the contexts anyway...

If you are dynamically adding extensions to a context, then whatever
mechanism that adds/subtracts an extension to the db, should be able to
also call these functions, via CLI/manager/whatever interface...?

murf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070328/a18f3426/smime.bin