More often than not, our customers have mutliple DID, sometimes up to 100 per customer. We have been discussing ways to improve the setup process.
A simple addition that would help a lot for setting up the inbound routes would be a "Create and New" button when creating routes. This would essentially create the current record, but stay on the screen allowing the user to create a new route without going back to the route list.
Other systems we have take this idea a step further and have a Save and Clone feature which will give you a new record based on the current entry (which is also very helpful).
BTW, has anyone else reported or experienced the really slow load time on the create route page? Getting to the buttons at the bottom of the screen seem to take an extra 10 seconds.
Brian
The reason for the slow page
The reason for the slow page load on the create route screen is that all of the options for all of the available scripts to use as targets for that route are loaded in the page (and just hidden). If you change the target script, you'll notice the options below it change for the arguments to pass to that script. So the more scripts you have available as targets for inbound routes, the longer it'll take to load that page.
This is a page where I can see it being a good excuse to use some AJAX... pull in the arguments on-the-fly as the select-box is changed to each script, instead of having them all pre-loaded. Of course, the tradeoff is you'd have a short delay before you could do anything each time you changed that select box.
hello are there any plans on
hello
are there any plans on trying to move the config files to mysql db and change the codes on the webpages.
what hardware does you guys use and how many tenants, concurrent calls and concurrent logins on the webportal do you have? im want my customers to do about all their work by their own so im a bit concerned that they will complain that the portal are too slow.
the slowest pages are the ivr
the slowest pages are the ivr pages because of the way it loads all the data of every possible script ... a more dynamic method is being looked into.
speed improvements
Yes, some of the more dynamic pages are slow, and yes, there are plans to improve this - both in terms of page design and in terms of moving things to the database where possible. it is a fairly big project but it will happen.
Thank you for the quick
Thank you for the quick answer. I was getting really concerned yesterday when i noticed this issue.
If i have a server that looks like this:
* Intel® Xeon® E5504, 2.0Ghz, 4M Cache, 4.86 GT/s QPI, 800MHz Max Memory x2
* 8GB Memory for 2 CPUs, DDR3, 1066MHz (4x2GB Dual Ranked UDIMMs)
* 146GB, SAS, 2.5-inch, 15K RPM Hard Drive (Hot Plug)
* Gigabit ethernet
I wonder if it will get slow with 20 concurrent tenants that have administrators that are in the system on a daily basis and do changes to their tenant. Or are we talking 10 tenants? The tenants are about 10 user each, so it will be easier to calculate.
It would be nice just to have a hint where we stand today.
the worst delay i've seen is
the worst delay i've seen is on the inbound routes and it could take between 30 seconds and 3 min to load the page to the point where the save button appears at the bottom. Honestly, why would you expect so many admins to be making so many changes on a regular basis? User portal is one thing but phone setup is mostly a set-and-forget. We dont even make that many changes as the top level admins apart from creating the new tenants and doing a dialplan interview.
Erik, thanks for the answer.
Erik, thanks for the answer. Im just curious since i have to do some investments here, thats all.
If you want you dont need to answer but how is your hardware on the servers? And how many tenants? Just want to know so I can put the numbers in the budget.
Br
Jörgen
intel xeon 5530, 8gig ram,
intel xeon 5530, 8gig ram, server grade network cards fault tolerant hardware
yes, its inherently slow as a result of a few things. Its parsing a single file so the more you add, the longer this will take. Its a design problem that to fix, requires a complete re-write. You'll also notice that webmin will log in and out of the AMI like 8 times on a simple page load as well.