| |
[Voip.ms] WOW! VoIP.ms portal speed fixed?I've only been with VoIP.ms since 2/22/14 and today for the first time their portal speed is nearly instant response. I wonder if they fixed something?
OE |
|
| |
I think it's been like this for a week or two... haven't noticed any slowdowns since then. |
|
| |
A short week, maybe. Good to hear it's not just me. I've been hoping they could fix something on their end. It's like a new feature!
OE |
|
| |
Registration status inquiries has gone from painfully long to uncomfortably long. I guess that's an improvement but still way too long for the purposes of troubleshooting
But otherwise, yes very quick now. |
|
| |
Not for me mrdialup... although I only have 4 devices. Maybe the number registrations matters. |
|
| |
I don't have many registrations. Maybe it's where I'm located. |
|
| |
to mrdialup
said by mrdialup:Registration status inquiries has gone from painfully long to uncomfortably long. I guess that's an improvement but still way too long for the purposes of troubleshooting My query takes 12s for 7 registrations with 2 servers (Washington and New York). Could be wide variability querying different servers/locations. I wonder if other providers do it faster. OE |
|
| |
said by OzarkEdge:My query takes 12s for 7 registrations with 2 servers (Washington and New York). Could be wide variability querying different servers/locations. I wonder if other providers do it faster. In my experience, everyone else it seems to be instantaneous. Like I said, it's better now but still not quick enough if you are trying to diagnose connectivity issues. And I can only imagine if you had over 10 devices, Voip.ms only displays 5 at a time (IIRC) so each new page would be added delay. |
|
| |
said by mrdialup:Voip.ms only displays 5 at a time (IIRC) so each new page would be added delay. Yeah, of all things, I actually submitted ONE feature request for them to list more than 5 registrations at a time! I figure if they can't get that done, there is no point submitting anymore ideas. OE |
|
| |
to OzarkEdge
Noticed their site was slow in general. Not just registration checks.
And I was thinking... is it possible the reason their registration checks are so slow is because the query has to go through ~dozen servers? Vs only 2 or 3 with other itsp's? |
|
| |
said by Alittlegreen:Noticed their site was slow in general. Not just registration checks.
And I was thinking... is it possible the reason their registration checks are so slow is because the query has to go through ~dozen servers? Vs only 2 or 3 with other itsp's? Is their site still slow for you? You may be right about the many servers to query. If so, maybe they could offer a user setting to restrict the query to just the user's servers. This would eliminate unnecessary server queries. But then again, maybe they already know somehow to do this. OE |
|
| |
said by OzarkEdge:You may be right about the many servers to query. If so, maybe they could offer a user setting to restrict the query to just the user's servers. This would eliminate unnecessary server queries. But then again, maybe they already know somehow to do this. They probably need to query all the POPs (servers in order to confirm registration. You (or me) as the end user could always pull a fast one and register to another server. That would keep 'em guessing LOL. |
|
| |
said by mrdialup:They probably need to query all the POPs (servers in order to confirm registration. You (or me) as the end user could always pull a fast one and register to another server. That would keep 'em guessing LOL. Right. But I'd be happy to restrict that query to just the servers I know I'm always using... to speed things up. If I 'pulled a fast one' as you say, I'd only be tricking myself. OE |
|
1 edit |
said by OzarkEdge: I'd only be tricking myself. See, you're smarter than me. Tricking is more complicated than fooling. A trickster tries to trick themselves and if they succeed that's a trick and that's clever. I on the other hand, would try to fool myself. And only fools can fool themselves, not because they are clever but because they are fools.  |
|
| |
said by mrdialup:See, you're smarter than me. Tricking is more complicated than fooling. A trickster tries to trick themselves and if they succeed that's a trick and that's clever. I on the other hand, would try to fool myself. And only fools can fool themselves, not because they are clever but because they are fools. Let's not have any of that self-deprecating subterfuge. I agree with you... 'tricking' is the wrong word... 'fooling' is more accurate. My life... our lives... is a fool's paradise. OE |
|
| |
to OzarkEdge
For a while, speedy response was intermittent. Sometimes it was fast, other times not, and especially when going to the main page when logged in. Recently, it's been quick more often than not. Definitely improving.
Pulling up registration information does take a long time. I also suspected it's because of the number of POPs being queried. I'm sure they'll get something worked out. |
|
| |
to OzarkEdge
WOW!! You're right, it's traveling at the speed of light   They changed the Registration Status check to a manual link, so now it doesn't take painfully long on the home page while the query is being processed. Great job voip.ms!!! I am a happy customer. |
|
| |
The home page used to still take a long time even after the registration status was separated from it. The continued improvements are certainly appreciated! |
|
MartinMVoIP.ms
Premium Member
join:2008-07-21 |
to OzarkEdge
Glad you guys appreciate the improvement. Our first goal was to eliminate the long loading time of the Customer Portal and the occasional "lock up" and make the navigation a more fluid experience. We're still working on optimizing it but at least now the navigation if fluid. (We've new hardware on the way).
Regarding the "Registration Query", which is a different story, the current system indeed queries all servers. Since we've added a lot of them lately, this method has to be reviewed and optimized and certainly has not gone unnoticed on our part.
We appreciate the feedback.
Regards, |
|
| |
said by MartinM:Regarding the "Registration Query", which is a different story, the current system indeed queries all servers. I would be OK with something like all of the servers being queried by default (to avoid confusing new customers) and the option to choose from a list of servers (i.e., just the one(s) we know we're registering to). |
|
| |
said by bitseeker:I would be OK with something like all of the servers being queried by default (to avoid confusing new customers) and the option to choose from a list of servers (i.e., just the one(s) we know we're registering to). Excellent suggestion, if they can't automate it further otherwise. OE |
|
MartinMVoIP.ms
Premium Member
join:2008-07-21 |
to bitseeker
said by bitseeker:said by MartinM:Regarding the "Registration Query", which is a different story, the current system indeed queries all servers. I would be OK with something like all of the servers being queried by default (to avoid confusing new customers) and the option to choose from a list of servers (i.e., just the one(s) we know we're registering to). Good suggestion that's something like that I was thinking. Like you said, place this in advanced settings to avoid confusion for non technical users. Another way would be some kind of mechanism that scan all servers every minute and compile list of registrations. The problem is it would not report real time. So we would have to put something like "Last update: time/date" and a button to query right now on that specific registration. Perhaps a combination of both would be great. I've added this to our project manager. |
|
|
| |
said by MartinM:Another way would be some kind of mechanism that scan all servers every minute and compile list of registrations. The problem is it would not report real time. Yes, I had thought about a scheduled report like that too. It does have the downside of having to wait for an update, however a minute isn't very long to wait for the next registration. Of course, you could do both. Have the scheduled report for at-a-glance checking of registration status. Also keep the on-demand button for those who really need to see the state of things "right now" and they can wait for the result to come back. Then, being able to select a subset of servers would be a bonus, but not really necessary. In fact, always scanning all servers can avoid having someone think something is wrong because they forgot to add a new POP that they started using. |
|
| |
to bitseeker
Since your server POP is stored in your DID information, what would prevent VoIP.ms from scanning only the servers configured as POPs for your DIDs?
I actually find it pretty hard to believe that the current method is to scan ALL servers. Would there ever be a situation where your ATA/device wouldn't be homed to your DID's configured POP? |
|
 toro
join:2006-01-27
Scarborough, ON |
toro
Member
2014-May-25 8:59 am
Some users may use the service for outbound only so in their case there's no DID/POP information. Or perhaps PBX users may have one POP for inbound calls but use 2 or 3 outbound routes to different POPs for failover purposes. |
|
| |
Ah, good point So, instead . . . upon ATA/device registration with the server, a function is called to update a central database with the sub-account ID and server name; that would also be updated when the device configuration was changed to point to a different server. The registration status reporting routine called from the web page would query that database for the logged-on account's sub-account IDs (while also selecting the servers they've registered with), then iterate through the result set and obtain registration status for only the servers returned by the query.* Should still be considerably faster than querying each and every server and should effectively provide real-time information. *Obviously, some programming required, and I'd rather have them work on other features before tackling this (one of which, answer confirmation, MartinM has apparently decided to stop providing updates on given the numerous "real soon now" statements over the last 3 years). |
|
toro
join:2006-01-27
Scarborough, ON |
toro
Member
2014-May-25 11:01 am
said by DoctorStinky:... that would also be updated when the device configuration was changed to point to a different server... The the voip.ms portal would have no way of knowing if a device's configuration was changed to point to a different server until at least one registration happens. I would say the portal could be programmed to "remember" all the servers to which the customer had registrations in the last X months or weeks, and query only those servers. If an ATA is changed to point to a different server, the entry to the previous server would expire after that interval. |
|
1 edit |
to MartinM
said by MartinM:Another way would be some kind of mechanism that scan all servers every minute and compile list of registrations. The problem is it would not report real time. So we would have to put something like "Last update: time/date" and a button to query right now on that specific registration. Make the cached server registration query the default one (that most people would use) and bury the on demand one somewhere within the sub-account menu(s). With the on-demand one, make the selection of registrations either ala carte or select all. The ala carte selection would be great for troubleshooting. That would be outstanding - good idea Martin! |
|
| |
to toro
said by toro:The the voip.ms portal would have no way of knowing if a device's configuration was changed to point to a different server until at least one registration happens. But it doesn't have a way of knowing that with the current setup either. So add another field to the registration procedure call, database table and web display that tracks the last registration timestamp. The user would then have an indication of when the device last registered, or if it never registered. |
|
