VoiceGuide IVR Software Main Page
Jump to content

Mysql Db

Recommended Posts

Hi,

 

I have a VG system with 16 lines and I'm using mysql as outdialing database.

 

When uploading for example a campaign of 5000 contacts, the porttouse table is then loarded with 3000 * 16 = 80.000 entries

 

If I do that 5 times for 5 campaigns, I have a database loaded with about 400.000 entries.

 

I have experience that VG was not running properly when I have a lot of entries in the bd.

 

So Is there any way to check if evrything is right on the db? How can I optimize tha?

 

I would like to increase to 30 lines but I have some concenrns about who it will work.

 

I need some help before increasing number of lines

Thank you support team

 

 

Mh

 

Share this post


Link to post

Databases like MySQL and SQL Server etc can easily handle tables of many millions of entries. Database is not likely to be the cause of any issues.

 

If you describe the problems that you experience (or post some traces) then we can better comment on what to look at.

 

Are calls allowed out all of the lines, or just on some of the 16 lines?

If a call is loaded without being limited to be dialed out on specific lines, then only one PortToUse entry is loaded for each call.

 

Also you can disable PortToUse table entirely - see the Help file for instructions.

You can do this if calls are allowed out on all ports, or if the ports used for outgoing calls are specified in the Config.xml file.

 

30 lines is not an issue. It is well within operational limits on any current hardware regardless of how complex the scripts are.

 

Share this post


Link to post

The point is that when I'm looking at the line status pannel sometimes lines are not placing calls. And have to wait for a moment before seeign lines working (1 minute sometimes)

Some time some capaigns do not start at all etc ...

 

- I'm using specific lines for each campaign, that's why I have to use porttouse table

 

Here is the last logs. Thank you

0626_1045_vgEngine.zip

Share this post


Link to post

Trace file is 7MB long and runs from 10:45:36 till 11:05:23 at what time did you observe what you describe?

 

Next time this happens please note the exact time at which this is observed and on which lines it is happening. We can then look in the trace and see what is actually happening on those lines.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×