Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

Answering The User Cry: 'The Network Is Slow!'

By Bill Alderson and J. Scott Haugdahl Q: Users at one of our remote sites are co mplaining of slow response time for a particular application that interacts with our mainframe. With this application, data is entered by a user, then it is verified by the mainframe for accuracy before the user can continue to the next record. This process normally takes a few seconds, but it h as escalated to as long as a half minute. This is not only causing a loss of productivity, but it is also affecting customer relations, since a customer often is placed on hold until the transaction is completed. Our remote site is connected via a fractional T1 leased-line running at 320 Kbps. The remote and local routers that service the T1 look clean, with no Cyclic Redundancy Check (CRC) errors on incoming packets and average T1 loads that are less than 20 percent.

Scott: Remember that old cartoon with the skeleton at the keyboard with the caption "Computer been down long?"

Bill: Sure do. Now the caption should read "Net work been down long?"

Scott: These days, the majority of problems perceived by users are blamed on the network, not the workstation.

Bill: Therefore, our first job as analysts is to verify that the problem is not workstation-related.

Scott: One "slow print job" that we investigated ended up being a printer that would run out of paper now and then.

Bill: It turns out the recipient of the print job hadn't a clue about flashing lights on the print status panel.

Scott: After all, it was someone else's job to keep the printer bins full.

Bill: And once the paper was replenished, the print jobs would print.

Scott: Of course, the "latency" of this particular problem could be rather high, depending on when the printer administrator got around to the refill!

Bill: Now, having a mainframe verify some input information probably doesn't involve printers.

Scott: A quick trace off the ring to which the mainframe's front-end processor was attached showe d us some user verifications taking two to four seconds, in the "normal" range, while others were taking 12, 20, 40 seconds or more.

Bill: So, users appear to have a legitimate complaint. Could the response time be related to mainframe load?

Scott: One might think so, but before we started talking to those "big iron" information system folks, we needed to gather some additional basic, but critical, information.

Bill: That information included knowing all devices (including routers, switches, servers and mainframes) involved in the verification process, and the communication paths among those devices.