ITKnowledge Exchange member "JayCuizon" had a question about speeding up DOS applications through switch configuration, and fellow techies jumped in on the conversation and helped out. Here is a portion of the conversation. Read the rest of the thread.
Want to join in on a similar conversation? Register for ITKnowledge Exchange and fill out your profile so you can ask specific sets of people your IT questions and also help out your fellow geeks. Anyone can read answers already provided to questions, but only registered ITKnowledge Exchange members can ask questions or add to threads.
|ITKnowledge Exchange member "JayCuizon" asked:
Our network is composed of the following:
All Cisco 2950 switches (gigabit port) are connected directly to the Cisco 2970 gigabit switch. A few workstations are connected to the gigabit switch. We still have Clipper 5.3 DOS-based applications in our Netware server, which is accessed by 75 workstations via mapped drives. All DBFs are accessed directly using Clipper Native File access. All applications are running fine without any problems.
My question is: What would be the best configuration for the Cisco switches and LAN equipment in order to make my DOS based applications run faster?
With the equipment you have (no router), you won't be able to do much. You could monitor your server connections to ensure that you have your MTU adjusted to the best size for your network/applications (servers and clients). You could increase available bandwidth on congested links by using etherchannel. Make sure all of your interfaces are set to the highest speed and proper duplex of the server and client NICS. It also sounds like you have your switches set up to obey the 5-4-3 rule. Keep your patch cables as short as possible in the closets and at the workstations. Don't overextend your max distances on cables, etc.
However, there's not much in the way of switch configuration that's going to speed up the network without a router. Even then, you might not get any benefit out of WFQ, CBWFQ, etc. if your network is not experiencing any congestion.
I've heard that your servers should be on the lowest number interfaces for the groupings on the Ciscos, but I don't believe it. The guy explaining it to me said that they have a "higher priority" on those ports when/if the Cisco is congested, but I've never heard anything useful from this guy, so I highly doubt it's true. According to him, ports 1, 13, 25 and 37 on the 2950 get the highest priority when the switch is heavily loaded. I've never tested it or found it anywhere in writing, however.
You are headed in the right direction to look at the client and the server for the tuning of the app. When you refer to making DOS run quicker over the wire, technically DOS does not do anything over the wire -- DOS uses TCP/IP to do its communication, and the only thing that can make that faster is good programming on the application and good throughput on the switch.
I like to set all my ports duplexing and turn off auto. If you look at your switch ports and see errors, check them. If you have the ability to sniff packets, see where there may be some latency or performance issues. You can try putting static routes for client server access. Even try the DOS app on a different VLAN, secluding it from the rest of the network.
Your issue is not the network -- I am sure that if you monitored the traffic, you would find it is using a small percentage of its capacity.
The areas to look at to increase performance are:
- Disk access -- disk speeds, RAID configuration, etc.
- Memory usage -- more always helps
- CPU usage -- see if this is a bottleneck
- The application itself -- although Clipper/DOS apps support multi-user, they do not scale very well. That is why most applications use a SQL-based database instead of direct file access. This is the area most likely to be your bottleneck, but also the most complicated to resolve.
If you don't have it already, I recommend you set up MRTG. This will allow you to know if you have any network bottlenecks.
As far as the server is concerned, Novell has some articles on server optimization.
If the server hardware is the bottleneck, there are some things that could help significantly. Our backup server was taking over 24 hours to back up all of the other servers to a single RAID using two parallel jobs. When I optimized it to use a mirror for the OS and stripe two SATA RAIDs for the backup data, the speed went up dramatically. Now our longest Gbit backup is nine hours, and the 100 Mbit backup dropped to 15 hours. When I finish optimizing the network by running all of the servers on Gbit, I expect full backups to take under 10 hours.