MXe-III performance improvement

[rikko]

Hi All,

I find my MXe-III units to be rather slow. Did anyone have this impression, and did you try to improve the response?
I'm thinking about the things such as the RAM increase, ethernet interface replacement with Gb units (not sure if it's even possible), SSD/SAS installation...

Cheers

[acejavelin]

What issues are you having exactly? I mean, it isn't a regular "computer" per se (I mean, it's a computer, but more of a dedicated application appliance)... Adding more RAM won't help or make it faster... Oddly, adding an SSD won't make it faster, except minor reduction in boot times... And MXeIII already has gigabit Ethernet.

If you want it "faster" then virtualize it... It will reboot quicker and boot faster, but it's still a system emulating an older system and even on high end virtualization hardware with WAY more resources than it needs, it still is laggy and slow to do things like searches or bulk changes.

If your issue is boot/reboot times, the best way to speed that up is disconnect the Ethernet cable(s) while it's booting so it doesn't get hammered with DHCP or TFTP requests while booting. It does help, we do it in some upgrade scenarios.

[rikko]

Thanks for pitching in. My primary problem with MXe-III is overall response. Like, anything that I do through a web interface, be it accessing Users and Devices, or exporting a form, or generating a backup, you name it, it takes what subjectively forever in comparison with two virtual nodes in the system. And this is the same with both of my MXe's. Unfortunately I do have to keep them, as they're sort of acting like a gateway to satellite telephones, which currently require a plain analogue connection. In the future I guess none of that stuff will be needed, but who's gonna wait until then.

Ok, good to know it already has a Gb LAN. So then there's no means in increasing processing power (other than virtualization)?

[lundah]

Thanks for pitching in. My primary problem with MXe-III is overall response. Like, anything that I do through a web interface, be it accessing Users and Devices, or exporting a form, or generating a backup, you name it, it takes what subjectively forever in comparison with two virtual nodes in the system. And this is the same with both of my MXe's. Unfortunately I do have to keep them, as they're sort of acting like a gateway to satellite telephones, which currently require a plain analogue connection. In the future I guess none of that stuff will be needed, but who's gonna wait until then.

Ok, good to know it already has a Gb LAN. So then there's no means in increasing processing power (other than virtualization)?

The software is designed to run on the supported hardware as it's configured. There's no way to DIY performance improvements on the proprietary hardware that the software is written to specifically support.

[ZuluAlpha]

I have seen this happen with a failing RAID controller where it's like painfully slow - not a little slower than virtual. The failing RAID controller for some reason won't always generate an alarm for me.

[lundah]

I have seen this happen with a failing RAID controller where it's like painfully slow - not a little slower than virtual. The failing RAID controller for some reason won't always generate an alarm for me.

That's entirely possible. and if it's not RAID equipped, could be a failing HDD.

[Dutch]

Thanks for pitching in. My primary problem with MXe-III is overall response. Like, anything that I do through a web interface, be it accessing Users and Devices, or exporting a form, or generating a backup, you name it, it takes what subjectively forever in comparison with two virtual nodes in the system. And this is the same with both of my MXe's. Unfortunately I do have to keep them, as they're sort of acting like a gateway to satellite telephones, which currently require a plain analogue connection. In the future I guess none of that stuff will be needed, but who's gonna wait until then.

Ok, good to know it already has a Gb LAN. So then there's no means in increasing processing power (other than virtualization)?

Back in the past the physical servers were ALWAYS slower then their VM counterparts. can not compare.

The only thing that could improve performance depending on the situation was increasing the memory and installing a second CPU board (going to a 1000+ user config)

Still can not compare to VM and Hyper-V deployments. I would suggest going to ATA converter for the phones wether a multiple port device or a single line. Then again why do they need to be analogue and is there maybe another way to circumvent single point of failure situations due to analogue devices.

[rikko]

The only reason there's analogue connectivity is due to back-compatibility with outdated systems (none physically present atm). Each hardware piece in our communication chain supports at least SIP, so that answers that. However, much like in every other large business machine, change is not always welcome, particularly if it involves expenditure of monetary resources.

Appreciate your response.

[Dutch]

The only reason there's analogue connectivity is due to back-compatibility with outdated systems (none physically present atm). Each hardware piece in our communication chain supports at least SIP, so that answers that. However, much like in every other large business machine, change is not always welcome, particularly if it involves expenditure of monetary resources.

Appreciate your response.

I would make a global inventory and categorize on modem or non-modem analogue devices. If modem I would investigate wether they need to be as opposed to different solutions. That said in NL the use of modem devices at the moment is a thing of the past (10+ years ago with building management servers and stuff which I had to deal with which were connected to a physical Gateway).

That remains Fax/Analogue Phone devices. You could always plan a small project to migrate them to SIP. Not sure if there is any Cloud or IP-VPN situations where local devices need to connect to cloud, but even if this is the case and if there is many analogues you could for example go with an Audiocodes or a different solution connecting the analogue devices and even get some marginal resiliency connecting them to virtual MiVBs.

In my experience if you put in some time you might find out that you should be fine ditching the physical single point of failure gateways (hardware yikes) and migrate to a more robust centralized situation.

Change is hard for many. Start small and show it works and create some base of support. It might just sell itself. In current times I you don't want to be dependant on possible non-resilient hardware that can fail with non-resilient analogue stuff.

These days its not hard to migrate to SIP on a per port basis and in the end remotely phase out the physical Network elements.

My 2 cents and I hope the above is a bit the answer you were looking for.

[rikko]

Hey Dutch,

you make valid points, I would have to give it some thought. Though, the direction where my job is heading may not be in line with the proposition. For the time being, I'm in peace with MXe's being turdishly slow.

Thanks for the explanation.