Hi there.
The UI for the end users is dreadfully slow (to the point of being unusable at times), with page load times from 6 - 10 secs at a minimum for the call forwarding page. It looks from the forum posting that this is related to use of inefficient function calls and the flat file configs rather than db for config. Is this on the roadmap to be fixed?
Also, I note that you have in previous errata / release notes said that page cacheing was disabled as Opera was aggresively cached - is this for all pages? Again, the call forwarding and other admin pages for end users appear to cache in Chrome (but seem ok in IE).
Do we have to insist to our customers to use IE only with the Thirdland platform.
Rgds
Aydin
Would an AMI proxy speed up the UI?
Thanks loads Erik - in that case, would implementing an AMI proxy help us speed up the user experience by taking the AMI onto a separate server and giving that as much resource as is needed / available, or would the problem remain somehow as i t has to go back to the source config files somehow?
e.g.
http://www.voip-info.org/wiki/view/Asterisk+Manager+Proxy
What would you propose is best practice? There must be a way of making this better, surely?
it wont reduce the number of
it wont reduce the number of queries to the AMI. Theres a long term plan to use a MySQL database for these value/key pairs through dialplan but its a major evolution and wont be backward compatible to the current LTS version. There will be no upgrade of an existing server to this design, users will have to be migrated over. This will be arriving sometime after the new LTS release stabilizes.
There must be a better way?
Ok - so does that mean that performance must remain substandard?
Can we perhaps not move AMI daemons onto separate servers from the ones that do RTP proxy, vmail, IVR etc? These are the only ones that will affect call quality surely, as the other features are call control and are less sensitive to latency due to improving priority for AMI daemons?
Is there really no best practice for making the user experience better?
Has no one else really not complained about performance? Are there any other users out there who might have found a way of working around these weaknesses?
in a word .. NO I have over
in a word .. NO
I have over 900 handsets and less than 50 have ever logged into their user portal, and those less than once a month. Theres really nothing in the portal that they would be clicking all day long where performance really matters. They go in, make a change, log out. Or they go in, activate their flash application for agent panel, and its still not refreshing so they see no slowdown.
im not saying its not on a list of things to work on, its just not at the top of it.
FYI this is about to get
FYI this is about to get worse... users are now suggesting turning pbx manager into a CRM full of reference material about the customer. As if loading actual pertinent data about settings like forwarding, FM/FM, screening etc weren't time consuming enough, now data you don't need can get loaded as well like your favorite color, your kid's birthday, what state you live in and what kind of car you drive (ok some exaggeration but the principle is the same).
see the end of this thread
firefox works better than IE actually. the interface is developed with firefox, and often has to get some manner of hack just to get it to work with IE because of their non-standard-ness. So IE sometimes display things a bit differently (like the move up/down buttons in huntlists).
user portal is slow because, unlike the admin portal, it has to do a LOT of reads from the ASTDB which it cannot do directly. This involves querying asterisk through the AMI. Finding methods of prioritizing AMI lookups like that would come at the expense of call quality I'm afraid. Whats more important in a phone system.. the phonecall or the webpage? You only get to pick 1 for priority.