Faster Script Processing?

[Guest vgfan]

Having used VG for 15 months, and I'm highly satisfied with this superb product and the fantastic support I get

 

One performance aspect I always want to improve is this: VG works like an interpreter and so every time it handles an incoming call, I can see the event viewer loading the scripts and then execute the codes. Over time, my scripts can become long and the time delay will become too long for my impatient customers! I tried to improve it by including more processing in stored procedures such that the scripts will be much shorter to have to invoke the SP only. This certainly helps.

 

However, may I ask if I still want to improve this further, would it help by compiling the codes to some COM or executables, and then invoke them in vgs using RUN module?

 

I'm not familiar to these approaches and so I would like to seek advice it, and only start on this path if it is a feasible solution that should bring noticeable performance improvements. If 'yes', please also advise some 'quick start' or samples for my reference.

 

Many thanks!

[Guest vgfan]

Oh... forgot to mention. In actual use, I have turned down the logging level to save the time to write out to the event log.

[SupportTeam]

Are you referring to VBScripts which are ran from within VoiceGuide?

You can of course just replace them with your programs which you can then call from a Run Program module. Using Visual Basic to do this would probably be the best choice.

 

The process of starting the VBScripts should not be that long - do you have any traces which would show where the delay is?

 

Having the Log Trace windows visible will also markedly slow down the system.

The Log Trace window is not meant to be kept open when you are taking calls - just select for logs to be saved to disk and/or select the trace level and close that window.

[Guest vgfan]

Yes, I was referring to VB Script processing. I am also aware that I should not let the events window open in real cases and use minimal, or even turn off, logging in production.

 

The problem I face is a rather delicate one. For instance, when I arrange an outgoing call, it is typical I set an 'Init' vb module at the start for defining the Results Variables for pathnames, constants and run a stored procedure to retrieve call related parameters. The time required is only around 3 to 5 seconds, but customer's feedback have been highly critical towards this delay. Most callers are very impatient in our part of the world; when people pick up a call, if they did not hear an answer within around 1.5 seconds, they would already think that the call is invalid, and would tend to hand up. Likewise, I could not try to play a music when the script runs --- that would immediately signal to the recipient that this is an automatic system call, and the user will hand up even faster! (Too bad that I think many vendors have mis-used technology and created voice call 'spams' that have arounsed much negative publicity.)

 

So back to the main point, I need to minimize every fraction of a second as much as possible. Hence, if the alternative approach of running an executable will bring an overhead for 1 to 2 seconds, it may not be a suitable solution for me.

 

By the way, to share with others interested, I find a very noticeable speed improvement by using vb to invoke SQL stored procedures than to run a query.

 

I know there may not be any clear solution to my question, but anything for more my consideration is appreciated. (For instance, I understand we cannot set 'global' variables that applies to all calls. If that is available, some savings in setting RV could be saved --- something perhaps you may consider in the enhancement plan.)

 

Thanks,

[SupportTeam]

when I arrange an outgoing call, it is typical I set an 'Init' vb module at the start for defining the Results Variables for pathnames, constants and run a stored procedure to retrieve call related parameters. The time required is only around 3 to 5 seconds

I'd say the majority of this time would be spent awaiting reply form the database - the time taken to start the VBScript and call any VoiceGuide COM interface functions from it (to set RVs etc) is in small fractions of seconds.

 

Note that you can specify the Result Variables which are to be used by outgoing script at the time the call is queued, no need to wait till start of call to set them

 

See strRV field description here:

http://www.voiceguide.com/vghelp/html/DialListInto.htm or the Variables field here: http://www.voiceguide.com/vghelp/html/modD...honeMessage.htm

[Guest vgfan]

Thanks indeed; it's helpful!

 

Interestingly, you reminded me on my stupidity! ... because I have already been using this approach to set the RV list when I queue a call to the call list. However, later on, I forgot about this setting in the SQL trigger that set up the call and repeated the setting of RVs in the init VB!

 

By the way, may I clarify 2 more questions:

 

1. If I set the RV in the Dialer_OutDialQueAdd, the RVs will actually by loaded BEFORE the call is made? Hence, in this way, I will greatly solve the problem I raised!

 

2. In COM, using the RvSet_RvList is more efficient than individual RvSet because the operation is done once. Am I correct? (I was guessing that the internal operation for RvList will not parse the variable strings and than run individual RvSet to set the RVs.)

 

Once again, thanks for your help!

 

Cheers,

[SupportTeam]

If I set the RV in the Dialer_OutDialQueAdd, the RVs will actually by loaded BEFORE the call is made?

Yes.

In COM, using the RvSet_RvList is more efficient than individual RvSet because the operation is done once. Am I correct?

It will be quicker, but you are saving milliseconds here as each call to RvSet takes hardly any time - look in the VG trace, you will see timestamps next to each call made.

[ktruk]

VGFAN: you CAN set global RVs in the VG.INI file... they work great!

[Guest vgfan]

Yes, thanks all for helping! I'm now using this feature that I may have missed earlier (or the feature was not then available).