Maintenance notice May 20-21. Click here for details.
I haven't dealt with MAS90 much, but have with other ERP's. This client has always had all of their MAS90 users rdp directly into the mas90 server. They have outgrown their current terminal server, therefore I installed another ts to reduce the load on the other one. I installed the MAS90 client on this ts, and while it works, the client is complaining that the pages load slower than the other one. I do agree that the pages load much slower than other erp's that I have used for other clients. I just followed the basic instructions of mapping a drive and running setup from the mas90 folder.
Is there something else I should have done, such as any install or procedure?
Woody1, it would be extremely helpful to know what version of MAS you are working with. Have you done anything with the AV settings? Query the KB for resolution ID 415534. It explains how to speed up the reports. How is the TS connected to the network. Is the NIC a GB or 100 KB. If not a GB, consider getting one. This will speed the connection considerably.
Server is using a gb nic
I will read the kb
I also removed AV from the new TS so see if it changed anything. Doesn't appear to be any speed change with or without Avast installed.
I did some tests, and it takes 4.2 seconds to open the Picking Sheet Printing Screen, or the Daily Drop Sheet Report screen.
Wouldn't creating a second terminal server effectively be the same as having a true workstation and a server? I.e. the network cabling now comes into play to communicate between the workstation and the server.
The reason for speed with a TS session normally is that the program is running at the same location as where the programs and data are stored, thus no network to slow things down.
A 4.2 second response time to open up a window is actually pretty good when truly networking. It would probably be slow for a "local" install.
In a "networked" environment, I start becoming concerned at 8 seconds and above.
I have to agree with the client that 4.2 seconds is a long wait when you have to wait 4.2 seconds between every screen load. Other ERP's that I have used have installed a db portion on the other servers where users are running mas90 to help speed it up. Is there nothing like that for this?
To answer your question, yes, adding a 2nd TS is just like adding a workstation. This client currently has every user using the MAS90 server as their Terminal Server because of the speed issue. I find this hard to believe that this is the only way to make this work...
I am not very knowledgeable about TS, but I would imagine in this case it is going to run much like a standard workstation...so what about virus software? If you mapped a drive, make sure you make it exempt otherwise it will slow things down a ton!
A program is only as fast as the hardware/network supporting it. Most of the time spent in opening a window is in loading the program component needed to run it. Sure there will be a little overhead of it initializing itself once it is loaded.
Just for grins, I just did a quick speed test opening A/R Customer Maintenance.
MAS 90 loaded on my local workstation (not network or file server) fires up in a little over a second. I will assume that to be the fasterst bench mark possible in my system..
Introduce the network to fire up MAS 90 at the server and I get about 3.5 seconds in my system. I believe the slowest piece of my system is a 100MB switch in between my workstation and the server. I would assume that a 1GB switch would result in some performance increase as the program could be loaded faster. This of course would assume no other piece of hardware is a more significant bottleneck.
Did a TS session to my server (TS server and MAS on the same computer - so no network in between) and I got just under 2 seconds. Not bad. Note that my server is not dedicated to being a TS server so I'm not competing for resources with other users.
With your TS server being on a different machine than the actual MAS program you have an intervening network which will slow things down. I would liken that setup to be similar to my second test.
What about moving the entire MAS90 install to the new terminal server and run it from the new server?
That makes the most sense to me.
Current configuration really took out all the speed advantage of the terminal server. It's really no better than workstation/server because the network cabling has been brought into play again.
While I really appreciate the feedback, I'm a little shocked that the recommendation would be to move MAS90 and only be able to have one mas90 access point. What if the scenario was too many Terminal Server users for one TS. I prefer having redundant Terminal Servers.
Thanks anyway for the feedback, its much appreciated. I had already suggested to the client to replace the 100mb switches with 1000mb switches.
woody1 wrote:While I really appreciate the feedback, I'm a little shocked that the recommendation would be to move MAS90 and only be able to have one mas90 access point. What if the scenario was too many Terminal Server users for one TS. I prefer having redundant Terminal Servers. Thanks anyway for the feedback, its much appreciated. I had already suggested to the client to replace the 100mb switches with 1000mb switches.
When you get slowness from the network (which is the case), its really difficult to troubleshoot. The gigabit switches "may" fix the issue, they may not.
Moving the MAS90 install would be the quickest and easiest way to get a better speed. Its actually quite easy too (MAS200 would require a lot more work), and basically would really take how long it took to copy the data over.
Actually, my point is that just about any program that runs a program that is on the server including the data is going to run slower across the network than on a "local" connection.
If you get to the point where the TS server can't handle the number of users, it's time to switch from MAS 90 to MAS 200 anyway.
I'm no expert, but it sounds like your set up was a lot like a company I used to work for. Our MAS 200 was set up on a server and up to 32 people were simultaneously logging in from all over the United States. Each had their own RDC log in, and their own printers. We had been using an older ProLiant Server and it was sluggish.
We upgraded to a new ProLiant last November and that made a huge difference. A couple of other tweaks I made were to use the GB switches and NIC cards and the E3000 from Cisco for the T-1 line. Also, I used the old server as a print server so the resources for printing hardcopies wasn't being used up on the MAS server.
Another little trick I used was making sure the customization for lookups was pared down. For instance, when looking up a customer's account number for a sales order, just hitting the F2 key would bring up all 24,000-plus customers, and all the defaulted information. That takes a lot of resources. Most sales people didn't need all that, they just needed name, address and maybe phone number, and usually, they only needed it for the customers in their area of the country, so they didn't need to have all the customer's load up. If you're having 25-30 sales people always looking up all those names, that could be slowing down other parts of the system.
You mentioned picking sheets. This was another one I tweaked because it seemed to also be the slowest form pulled up. A picking sheet is nothing more than a form for the shipper to read and pull the products listed. The default form had all sorts of useless information on it, so I culled that information to only what the shipper needed to do his job. There was no need for a logo, no needed for extra client information, etc. What wasn't needed, I deleted from the form and it sped up significantly.
Oh, one other thing was to limit users access to the internet while on their remote desktop. I had that sucker locked down tighter than the knots on an Army boot. You get four or five users accessing the internet from the remote desktop, looking up parts or downloading manuals or watching their kids' YouTube videos, it tends to suck the speed out of a server and hog bandwidth like no one's business. we had just the one T-1 line and once the wasted bandwidth was cut down, things went much much faster.
Long winded as this seems, the short form of my advice is to shrink the look-up information, move your print server to another server and use GB switches and modems.
I hope this helps.
Also to hire me as the company I work for went out of business.
© 2015, Sage Software, Inc. All Rights Reserved. Sage energizes the success of businesses and their communities around the world through the use of smart technology and the imagination of our people. Sage has reimagined business and brings energy, experience and technology to inspire our customers to fulfil their dreams. We work with a thriving community of entrepreneurs, business owners, tradespeople, accountants, partners and developers who drive the global economy. Sage is a FTSE 100 company with 14,000 employees in 24 countries. For more information, visit www.sage.com.
Community Terms of Service | Community Guidelines | Blog List | Community Help