Re: Powerbuilder to Informix - Poor Network Throughput
Posted in 1996
Greg wrote: > > Yeah Kevin, I hate to be the bearer of bad news, but if your current LAN and backbone > aren't currently saturated, the FDDI backbone alone ain't gonna do it. The problem is > somewhere in the software - it can't efficiently use whats there. I get the same thing > on Sunday afternoon when I know there's nothing happening on my ethernet, relatively > little on the backbone, & nothing on the server segment. Throughput still sucks. > > We should be getting some help from our network/router engineering group soon, so > hopefully they'll be able to help me figure out the rest of the story. I'll post > anything profound that comes up. > > Kevin Daly wrote: > > > > Greg wrote: > > snip... > > > > I'd be interested in seeing this too. I have the same problem Informix > > to Access (or any ODBC connection) and to Informix NewEra applications. > > Same version of Online, server is a Sparc 20. I don't have an FDDI > > backbone yet but will in a month or so. I was hoping that alone would > > solve the problem but it sounds like not. > > > > kjd I guess I did not get my message across the first time. Let me restate it again. We are running Informix OnLine 7.1/7.2 on Sparc 20s (10GB to 60GB hard disk), Sparc 1000E (20GB hard disk), and Sparc 2000E (one tera byte hard disk). Our clients are PCs with Powerbuilder 4.x. But we are using Informix native drive instead of ODBC (I have heard many times that people have performance problem with ODBC drives). Our network is not ethernet. It is token ring, and we are not using FDDI (discussing the problem of FDDI is another subject.) The most important thing is OUR APPLICATIONS ARE IMAGE APPLICATIONS. We store images, retrieve images, and update images on-line. Yet we don't have performance issue. We did experience a lot of performance problems in the past. Almost all of them turned out to be network problems. Either network hardware problem or network configuration problem. One of our performance problem was resolved by installing a second CPU on a Sparc 20 server. One way to CONFIRM your network problem is to enter the following two commands at the server side: arp -a netstat -r If you don't have spontaneous response, you MUST have network problem. It sounds simple but takes us a long time to learn the above RULE. When the result from arp -a pauses for awhile and then display an ip address, you can be sure that is the troublesome node (I do'nt mean that particular node itself has problems.) When netstat -r pauses, you may have router problem (we disabled 224.0.0.0 multicast setting in one of the startup scripts for performance reason). If you want you should also check out "snoop" command. If you are serious about performance tuning, please listen to me this time: DOWNLOAD SymBEL FROM SUN WWW. It is free and suggests ways to improve server performance. You will never regret to have this tool. Good Luck, Chao