Please forgive the mildly provocative title. The design of the AGI system looks really very well thought out. However, it seems to result in a certain ‘overload’ in some ways.As I understand it.
The dialplan triggers the need to call a module.
res_agi kicks in and the data being passed to the module is put somewhere.
The module is started (eg. as a cli php script)
That script then goes through the whole bootstrap process and instantiates and AGI, so that it can …
retireve the data
do its thing.
Now, I can see the beauty of this because it means that the module can have full access to the system and its data whilst being a completely autonomous unit.
But, for a module that just needs just the data and maybe one small access to the asterisk system, bootstrap is a big overhead for something that may be called more than once in a dial plan (for different modules). Furthermore, because it is running as cli, php caching doesn’t help. Each time, all of bootstrap is processed by a new php instantiation from scratch.
Obviously, one solution is to get a bigger processor.
However, perhaps there might be more elegant ways:
Is there a way for a module to receive data from res_agi without having to run through bootstrap and create and AGI interface class?
Or, how about adding more options to bootstrap so that more if the things it includes could be skipped?
Or, how about extending AGI so that all modules can be accessed via a POST to localhost so that php can be within the framework and cached?
What exactly are you trying to do?, it’s usually a very quick process if you choose the right language, perl is usually a good choice as all the libraries exist and are time proven, it’s what I use but it can be a bit of a religious war with php’ers all you are need in your script is to read from /dev/stdin and write to /dev/stdout you could probably do it in “visual basic”
Yep, they are. However, it’s not something we’re stressing too much about. The major startup penalty isn’t those. It’s all the old functions.inc.php modules that we’re trying to change to BMO modules. BMO modules are autoloaded when required, which gives you NO startup penalty.
I suggest you stick an ‘exit’ after that include of functions.inc.php, and you’ll notice that the startup for THAT isn’t all that high (especially on PHP 5.4 and higher). It’s everything else.
@xrobau In fact, I’ve done various timings. Those three requires (functions.inc.php) being the last of the three) take around 80% of the start up time at present. So diving out after functions.inc.php foesn’t help. Or did you mean before functions.inc.php?
@dicko I’m trying to optimise superfecta, as it is slowing down incoming call processing somewhat. For reference, the same issue is also visible with dialparties. The start up time for those two modules represent around 70% of the time between call arrival at the pbx and an extension being dialed in my case.
Consequently I’m in php-world, as that is the language used for superfecta (and, I think, dialparties).
Based on the links you gave, I’ve come up with a couple of ideas and I’m trying them out …
So, I have put a proposed patch in the framework block on github. I’ve doen three things:
Changed the way that the bootstrap_settings are set to their default values if they aren’t set on entry, hopefully my approach is cleaner and easier to extend.
Added three more options to bootstrap_settings so more parts can be skipped if required.
Added in a nuance in the BMO/Ajax class allowing ajax requests to come in from the server itself, as this may, in fact, be the quickest way fro some modules to access themselves because it means that the code can benefit from php caching. The nuance is simply to allow incoming requests to ‘127.0.0.1’ to proceed without authentication.
Not in this set of proposals, but I am also planning an “AGIlite.php” class for modules that don’t need all the options that AGI.php provides.
Out of interest, what is the process from here for freepbx updates being approved and ‘going live’? An idea of that process would help me plan the next few tweaks (AGIlite, and then speed ups for superfecta and dialparties).
Normally it’s along the lines of ‘Harass @tm1000 or me until we do it’ – I’ve been trying to do firewall stuff today so I didn’t even get a chance to look at your changes, but I did get the alerts from github about your updates.
Without promising anything, we’ll probably get around to looking at it tomorrow.
I don’t know for sure yet. Now that I know that you’re all happy with these various suggestions, I ma starting to gather real use timings for the various combinations of:
bootstrap (2 options): with and without speed ups
AGI (3 options): phpagi.pgp, AGIlite class, just include some AGI functions
Superfecta: use the class within the .agi code (as now), use ajax.
That’s 12 possibilities, so not too many. Once all of that is clear, I will post all the data with proposed changes to superfecta.agi and the superfecta project. I’m happy for you to wait for that before making a final decision, but I’m not sure that you lose anything by just pushing them through anyway - there may already be modules that can live without framework_functions, which is the single most expensive bit of bootstrap … but I haven’t looked into it that detail yet, superfecta fails if they aren’t included, sadly.
Now I’ve got 13 working, I’ve just had a look at the code and there have been a few changes to the control flow in superfecta. So that I don’t mes things up with some suggestions, is there a specific reason why superfecta.agi now calls callerid (as a new process) rather than the previous approach of it creating a superfecta class and calling that?
After reviewing the code superfecta.agi in 12+ does not call callerid.php as a new process. I don’t know what previous way you are talking about. I have a feeling you are not checked out into the right branch as 2.11 executed callerid.php as a separate process but that was years ago. See for yourself: superfecta/agi/superfecta.agi at release/13.0 · FreePBX/superfecta · GitHub
