Asterisk::FastAGI perl module

[mcargile]

So I looked into the FastAGI_log.pl script to get it to do some caching of the DB commands and noticed that it is not using the Asterisk::FastAGI perl module but rather a mixture of the Net::Server and Asterisk::AGI modules and was kind of curious as to why. If it was because when Matt started this script this module was not out or if there was some bigger reason. Among other things Asterisk::FastAGI has a sub called child_init_hook where they suggest opening the DB connections for each child. This way you can leave them open and not have the overhead of opening and closing the connections every time a FastAGI_log.pl is called. If there is not greater reason other than it did not exist when Matt was working on this script then I am planning to convert the script to use this module and the child_init_hook.

The CPAN page for the module is here:
http://search.cpan.org/~jaywhy/Asterisk ... FastAGI.pm

In order to pull it in from cpan I had to get the inc::Module::Install module first as Asterisk::FastAGI did not pull it in automatically.

[mflorell]

It looks like it's about 6 months old, so no it would've been done after I finished the FASTagilog code.

Go ahead and convert it if you want, but I'm not sure how much of a performance boost you would get from doing so.

Can you control the child processes in that module as you can with Net::Server?

Have you built production scripts with Asterisk::FastAGI?

[mcargile]

I am not sure if you can control the child processes but it says it can be configured just like Net::Server. And no I have not used it in production, however I plan on testing it throughly when done. As far as performance improvements only time will tell, It will defiantly cut down on the number of DB connections being opened and closed.

[mcargile]

I did some testing and yes it does support all of the same options as far as child processes.

[mcargile]

So I have rewritten FastAGI_log.pl to use the Asterisk::FastAGI perl module and have it so that it is only connecting to the DB once per child. It is also only reading in its configuration once per child as well. I have not yet gotten it to do the caching of queries (not a big thing just not enough time today). The script is working in performance testing mode. Agents are getting calls and hanging up correctly. I have not tested if everything else is working yet or not, and there are somethings I really cannot test like the queuemetric stuff. I plan on doing some performance testing once I have everything the way I would like it. If that pans out I plan on testing it with one of our clients. And if all goes well with that posting it to the bug tracker.

The big issue is now that the children are only reading in their configuration and connecting to the DB when they are started, any changes made to the configurations requires restarting FastAGI_log.pl.

Originally I planned on making it so that if you called it with the right option it would reload it's configuration. Problem is though only the child that handled the request would reload. I am instead thinking of making it check how many seconds it has been since the last reload and if it is larger than a configurable value reload. I plan on placing the variable in the /etc/astguiclient.conf file under VARfastagi_log_reload_time and making the default value 60 because any changes in Vicidial take upwards of 60 seconds to take effect. Does this sound like an acceptable solution?

Another option would be to create a configuration number in the DB and if the configuration number the child is currently using is less than the one in the DB reload. This way it would only do so when told. This method would take more work on the part of the person making a change. They would need to click a link or run an SQL query. And if they were to click a link someone would have to put the link in place. The configuration number could just be the epoch of when the link was clicked.

Anyways would like some input on this.

[mflorell]

This sounds great so far.

An /etc/astguiclient.conf config option would probably be best for storage of the refresh_seconds option.

Have you done any comparisons of the load with your new FastAGI_log and the current one?

[mcargile]

No I have not done any performance comparison yet as I am still putting the query caching in. I am basically replacing:

Code: Select all

$stmtA = "SELECT alt_phone,gmt_offset_now,state,list_id FROM vicidial_list where lead_id='$VD_lead_id';";
if ($self->{server}{AGILOG}) { $agi_string = "|$stmtA|"; &agi_output; }
$sthA = $self->{server}{dbhA}->prepare($stmtA)
  or die "preparing: ", $self->{server}{dbhA}->errstr;
$sthA->execute
  or die "executing: $stmtA ", $self->{server}{dbhA}->errstr;


with this:

Code: Select all

$errorStmtA = "SELECT alt_phone,gmt_offset_now,state,list_id FROM vicidial_list where lead_id='$VD_lead_id';";
$stmtA = "SELECT alt_phone,gmt_offset_now,state,list_id FROM vicidial_list where lead_id='?';";
if ($self->{server}{AGILOG}) { $agi_string = "|$stmtA|"; &agi_output; }
$sthA = $self->{server}{dbhA}->prepare($stmtA)
  or die "preparing: ", $self->{server}{dbhA}->errstr;
$sthA->execute( $VD_lead_id )
  or die "executing: $errorStmtA ", $self->{server}{dbhA}->errstr;


through out the code. This makes Perl hold on to the handle to sthA so the DB does not have to create a new one each time. I could not put this in before because Perl drops this stuff when there is a disconnect from the DB.

[mcargile]

So I have it working as best I can test. We will hopefully be testing this on a production box in the not too distant future. As far as performance testing is concerned I really cannot give any definite on if it is performing better or not as at present as we are running this on XEN virtual machines. Currently I do not see any kind of a drop in processor load on the asterisk system though like I said it is a virtual machine and I am not taxing it at all (five remote agents). I have not checked processor load on the DB system yet which is where we are likely to see more of an impact from the caching of DB handles.

On a side note I did pass the script through perltidy which made the code far more readable but it means that I cannot submit this as a patch as just about everything has changed. I also want to add a bunch more comments to the portions that I changed.

I am pretty sure that in the not too distant future we will be making similar changes to most of the core scripts as well as making some FastAGI transfer scripts.

[mflorell]

I'm glad you are making progress so quickly. i await your results of production testing and performance observations.

There is a plan in the roadmap to change all of the transfer and closer AGI scripts into a single flexible FastAGI script. It would simply take too much time for me to do at the moment, and the fact that you have to stop the AGI server script and restart for changes to go into effect is a bit of a frustrating point as well.