Rvs Being Transferred To Vbscript Module

[Guest Buzby]

Hi there,

 

Techie question - I've noticed that when switching on the Event Trace Log into VG's /log/ directory, some very big log files can get generated with my application.

 

I have examined the files and discovered that the biggest additions occur just before a VBScript runs, when VG adds a line into the log file which starts:

 

151357.97 4 rv ns [PathSysVoice]{C:\Program Files\VoiceGuide\system\voice\}[PathApp]{C:\Program Files\VoiceGuide\}[PathDataVm]{C:\Program Files\VoiceGuide\data\}[PathVgSys]{C:\Program Files\VoiceGuide\system\}[inband_ID]{#269}[scriptsPath]{C:\Program Files\VoiceGuide\Scripts\MyApp\}[scriptPath]{C:\Program Files\VoiceGuide\Scripts\MyApp}[$RV_STARTTIME]{22/12/2005 15:02:23}[$RV_DEVICEID]{4}[$RV_CIDNAME]{}[PathApp]{C:\Program Files\VoiceGuide\}[$RV_CIDNUMBER]{}[$RV_DNIS]{}[DNIS]{}[RUNAFTERHANGUP]{C:\Program Files\VoiceGuide\Scripts\MyApp\myappdisconnect.vgs}[DataPath]{C:\Notes\Data\MyApp\}[bData]{myapp.nsf}[ErrorCount]{0}

(etc.)

 

I'm assuming that this is VG transferring $RV variables over to VBScript so that they are available when WSCRIPT.EXE runs with my code.

 

This is fine except for one thing - I have quite a few global variables which get changed quite a bit during each phone call. It seems that each time I change a value, VG doesn't overwrite the previous value - instead it appends the new value to the existing $RV list.

 

So let's say I have a global $RV called 'ErrorCount', starting at value '0' and increase the counter every time some kind of error occurs, what happens is that after a while, my log file starts to look like this.

 

151357.97 4 rv ns (...Earlier RVs ignored...) [bData]{myapp.nsf}[ErrorCount]{0}[ErrorCount]{1}[ErrorCount]{2}[ErrorCount]{3}[E

rorCount]{4}[ErrorCount]{5}[ErrorCount]{6}[ErrorCount]{7}[ErrorCount]{8}[ErrorCo

nt]{9}[ErrorCount]{10}

 

After the call has been running for a while, I ended up with a huge $RV list (i.e. 500kBs - 1MBs worth of $RVs) being transferred in and out of each script that runs, and this leads to a gradual slow-down in performance of each call. The situation is only rectified when the caller hangs-up and calls in again - I assume this is because $RV list is cleared down at the end of the call.

 

If I turn the /log/ directory logging off, the call speed improves overall, but still shows a gradual increase in CPU usage and gradual slow-down as each call progresses.

 

Am I correct in my observations? Is there any way to overwrite/remove $RVs, rather than append them, and therefore meaning the data transfer decreases?

[SupportTeam]

How long are the calls? Keeping a history of all RV values for length of call helps in debugging and we've never yet had anyone find this approach affecting their systems performance in a negative way.

 

We've never seen scripts use 1MB of RV storage space before though... what sort of application are you implementing? Can you post the script here?

 

As you correctly observed, the RV list is cleared out at start of every call.

Is there any way to overwrite/remove $RVs, rather than append them, and therefore meaning the data transfer decreases?

Right now VG will keep entire history of all RVs for the call. This cannot be changed by user in the current version.

[Guest Buzby]

Hi there,

 

Thanks for your reply. The calls can be quite lengthy, and involve the VG script pinging lots of requests to a back-end database in order to determine the voice files to read, and the required responses from the user (e.g. number of keypresses etc.). The sequence is also determined by the back-end database, so in the VG script there is a loop which continues until the database says that the script can exit.

 

Each response from the user generates about 40-50 $RV assignments, thus when the loop is repeated 30-40 times (which is common), this means that we end up with 2000+ $RV declarations being passed each time a VBScript runs. Although the time per $RV assignment is small, once we get into these sort of numbers, we can notice a visible slowdown in performance of the script. The CPU also starts to hit the roof after the user has been on the phone for a while.

 

Unfortunately for commercial reasons, I cannot post the script here, but I am happy to send it to you, along with any log files you might deem appropriate.

 

It would be wonderful if this could be resolved as the script performs flawlessly otherwise.

 

Best wishes.

[Guest Buzby]

We've never seen scripts use 1MB of RV storage space before though... what sort of application are you implementing?

 

I suspect that our application is probably pushing the boundaries of what is regarded as a 'normal VG application'. The primary script is approximately 124kB in size, and contains around 90 modules, of which around 95% are VBScript.

 

Despite that I feel that VG is a robust and reliable application which is more than capable of serving the script's requirements, it appears to be the fact that we have built in large amounts of 'configurability' in the back-end database that allows our users to control everything that occurs on a VG call without having to mess around scripts themselves. Consequently we have to pass around lots of $RVs to help do the job.

 

I hope this gives you a better idea!

[SupportTeam]

To allow VG to handle these extra large RV sets a redesign VG's internal RV storage and replacement mechanisms would be needed. We can flag this as a performance issue - but as just about no other user is probably hitting these limits I'm not sure what urgency will be placed on the matter...

 

One way to resolve this quicker would be for you to get the changes done as a 'custom alteration' (this costs $) - contact sales@VoiceGudie.com for a price on this (quote a reference to this thread in your email).

[Guest Buzby]

Hi again,

 

As promised in my email, I am posting a sample script here which demonstrates the problem of performance degradation in VG as $RVs are modified.

 

Essentially the script is a very simple two-module loop in which the first module sets the start time that the loop began running, and second module does some 'work' then reports the amount of time that the loop took.

 

The 'work' is simply 250 repetitions of an $RV assignment of the same variable. Because the variable name is the same, one would expect the variable's value to be simply updated under normal circumstances. However, VG instead keeps a history of all the previous values of the same $RV, therefore each time the loop runs, another 250 $RVs are added to memory.

 

If you run this sample script in VG, when you first call in, you'll notice that the loop time is quite low. However if you keep clicking 'OK', you'll notice a gradual increase in the loop time and therefore decrease in performance from VG.

 

Realistically the loop time should be identical, or similar, every time the script runs.

 

I hope this helps! Best wishes.

rvtest.vgs

[Guest Buzby]

Sorry to chase this up, but I wondered if you had any joy with this at all yet?

 

Unfortunately this problem is causing quite a few difficulties with our use of VoiceGuide, and it would be great if a solution could be found soon.

 

Best wishes.

[SupportTeam]

The comments in the last Dec23 post from us would still apply..

[Guest Buzby]

Hi there,

 

Yes, I looked at the comments and emailed sales@voiceguide.com with a request for a quotation to fix this problem. However, I have not had any reply.

 

Best wishes.

[SupportTeam]

We have been advised your email is now beeing looked at.