[asterisk-dev] bug 6002- one last word

[Steve Murphy]

OK, I committed my fixes to bug 6002, reported by Luigi a long time ago,
to trunk.

It also resolved a suspended bug, 8574, incidentally, that was filed
against 
1.2, where a large dialplan (934 exten, 6719 extens, 31,876 prios) was
holding up
processing on a reload to the extent that call processing was
interfered, and timeouts were occurring.

I had developed some fixes and generated a test set for that, but the
reporter
never tested my fixes. I dared not commit such a large change set
without testing, so I closed/suspended the bug.

Well, the fixes for 6002 make the whole process slow down somewhat
horribly, 
so I ***had*** to solve the prob for 8574 also, just as a matter of
coincidence; so I re-arranged things so the actual lock-down time (which
keeps asterisk from processing the dialplan) was minimized.  But I had
to do it somewhat differently, so the work I did for 8574 was really
wasted (except maybe for the experience gained).

Well, I removed the aging 8574 branch, but saved the test data and gave
it a spin for fun. Here's the set up: in AEL, I had around 30 contexts,
maybe 180 extens, around 450 priorities; I included the test data into
extensions.conf, so now it
has over 1100 contexts, 14,000 extensions, and 84,000 priorities. 
The two total to 1147 contexts, 14,292 extensions, and 84,940 priorites.
This is a somewhat large dialplan... don't you think?

Anyway, since one small chunk is in AEL, and the rest in
extensions.conf, I start up asterisk, which loads both, then do a
"dialplan reload", which just reloads the stuff from extensions.conf...

time to read config file and form new dialplan:   ? not recorded
time to scan old dialplan and copy extens/priors 
to new dialplan from other registrars:              114,531 μsec
time dialplan locked to save/restore hints
and swap dialplans (old & new)                          4-5 μsec
time to delete the old dialplan                     106,104 μsec
TOTAL: 220,676 μsec

And, to do an "ael reload":

time to read config file and form new dialplan:   ? not recorded
time to scan old dialplan and copy extens/priors 
to new dialplan from other registrars:            4,171,990 μsec
time dialplan locked to save/restore hints
and swap dialplans (old & new)                            4 μsec
time to delete the old dialplan                      63,685 μsec
TOTAL: 4,235,679 μsec

Why the big differences? Well, AEL creates only a small dialplan, and a
huge amount of stuff has to copied to it from the other registrars.
That huge amount of other stuff is already in the new dialplan when
"dialplan reload" is executed; only a small number of things, mostly
from AEL, needs to copied, (although everything still has to be
scanned), so the 'dialplan reload'
goes quicker.

Note that even tho we spend a large amount of time processing these
dialplans,
the time spent with the contexts in lockdown mode is only about 4-5
μsec, which should not hurt dialplan processing at all!

I did not try to optimize the hint save/restore time. But I have some
definite ideas of how to do this, and if anyone finds that a large
amount of hint data is interfering with dialplan processing at reload
time, file a bug, and I'll fix it someday.

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080307/fd1545a4/attachment.bin