I have run a few tests to try and understand how we might improve the speed of execution of modules. To get the figures below I have used my set up (FreePBX 13 running on a pi B). This is a slowish set up, but the relative speeds should still give an indication of what is possible.
I did the tests using superfecta (as I know that module well). I was set up to have only one scheme, and for the scheme to have cache as the first source, and for the cache to have the answer in it. The same number was used each time.
I wanted to examine 4 variations on the standard superfecata module
AGI lite: Replace AGI with a lightweight version of the class, containing only the really needed code.
AGI functions: Replace AGI with an include with the needed functions.
Minimise Bootstrap: set the bootstrap settings so that as little as possible was included. This turned out to be impossible because as soon as the key include was removed an issue arose with BMO (see Should BMO rely on functions.inc.php)
Ajax: use a very stripped down version of the superfecta code to invoke the module via ajax and then return the answer to AGI (it used AGI lite). No bootstrap needed here.
Each version was run 10 times and the speed averaged.
The results:
Superfecta standard 5.97s
AGI as core functions 5.97s (no gain)
AGI as simple class 5.92s (10% gain)
Ajax 2.28s (60% gain)
This suggests to me that there is some merit in wokring on one of the following approaches:
a) Pursue the ajax concept. It requires very little alteration to the Superfecta module, but I am not sure whether it would work for other modules.
b) Continue to work on speeding up bootstrap.php so that it can streamline the loading of modules.
1&2: Should not be done, we don’t need to maintain yet another version of the AGI files
3: Would have to look into this
4: The module should never invoke AJAX. I am not sure what you mean by this anyways. When @xrobau said use ajax he meant use the same setup ajax does. Not use ajax.
Perhaps I am using the term ajax wrongly here. By it, I mean that the superfecta.agi module would send an HTTP query to the server (as the web page does when you ask it to test the scheme) and the sends the callerid from the response back through AGI. As you can see it is substantially quicker than the current method. Add half a second for using the full AGI interface and it is still twice the speed.
That’s what we mean. That’s a terrible idea. It’s only quicker because Apache caches the requests but this is something that should NOT be done at all (We talked about what you were doing internally and both decided that doing this over http from the cli is a bad idea). Too many headaches. It also opens the server up to exposure and adds an extra layer of trouble. Stay on the CLI please, it’s always faster.
What we REALLY should do is work on something for 14. Unfortunately the patches you proposed recently broke 13 installs. That’s not your fault but it brings up the point that I can’t accept these types of patches into 13 any more. Moving forward it will all have to be 14 code.
I absolutely understand that this is getting too complex for 13, especially given the clash between my changes to bootstrap and 13.
And I understand your concern about using an http request (although the security hole is pretty small as you are only accepting requests from 127.0.0.1, and you could add the caveat that they must have been sent to 127.0.0.1) - but it does provide an idea of which should be possible if bootstrap is minimised and the code is lightweight. If caching could be taken advantage of, I would assume that that was a good thing, but perhaps the team is of a different view.
I’m more than happy to work with you guys so that 14 has a design which allows modules all the flexibility of the current system but also allows them to run as lightweight as possible. I have no doubt that a lot of work has already been done on this.
Anyway, I will stop posting and making suggestions about 13; I am ready and willing to help with 14 as and when you are free to have the discussion about it. I’ll ponder it in the meantime.