Tracking the elusive seconds - a continuing series on implementing a client/server system - Technology Transfer - Column - Tutorial

Last month we observed how Acme Services identified and attempted to resolve the political problems that can arise with the move to client/server systems. Now that implementation is under way, the firm faces the challenge of unanticipated technical problems.

Acmes new client/server-based customer service system was suffering from unacceptably slow response times. Alex, a member of the Strategic Planning Group who had a wide range of expertise, had been enlisted to help find the source of the problem. He had been asked to work with George, a senior PC mer, and Sally, a systems programmer. George's previous analysis seemed to indicate that all components were operating acceptably and no system bottlenecks existed.

Alex began his first meeting Sally by exploring host portion of the application. Sally told Alex that she had analyzed both CICS and DB2, and she was certain that they were not the source of the problem.

"George, what do you know about what's happening on the PC and the LAN?" queried Alex.

"We have very little data about actual performance on the PC," George answered anxiously. "The LAN itself does not appear to be overloaded. Message traffic appears acceptable. The file-server also seems to be operating normally. The PC is across town, but the LAN is connected to a fairly high-speed line. I asked Norma in Network to check the line -- it's pretty dean and not very busy. I've reviewed everything several times, and nothing appears constrained,"he added.

"George," Sally asked, "how does the PC itself look?"

"That?s hard to tell," said George. "As you know, we don't have anything to measure processing inside the PC, but we can look at the LAN. At this point, the problem does not seem to be in the PC itself."

"I heard you picked up a new PC monitor -- a snooper?" Sally asked.

"Actually, the LAN people picked up the snooper," George clarified. "We can connect it to a LAN and trace everything going around LAN. In fact, with model we bought, can hook it to other as long as they are through the right kind of gateways." George said he had asked

Norma to use the snooper to trace the customer service transactions. He then suggested that they all drive to the customer service center to watch the PC while the LAN was being monitored.

As they reviewed the trace information, Norma guided them through the data. Finally, Alex noticed something unusual. "Aren't there a lot of sessions between the PC and the host for the number of transactions we observed? Is that unusual, or am I missing something?" he asked.

"You're right -- that isn't normal, Alex. It seems like the application is sending several requests to the host for each logical transaction," Norma replied.

George was enthusiastic. "Alex, I think you've hit on something. There is a lot of traffic for the amount of work the users were doing."

"George, have you ever asked Vinnie the Vendor exactly what the programs were doing on the PC?" Alex asked excitedly.

"We have, but they were somewhat evasive. Maybe we need to dig deeper."

Alex, George and Sally set up a conference call with Vinnie. After some probing, they learned that the package would visit the host several times per transaction to obtain information from the DB2 database. They also learned that they would need a higher-speed line for the type of activity that was planned.

George was fuming. "Why didn't you tell us that before we bought it?" "Look, we don't really have all the answers," Vinnie answered a little defensively. "The product is new and there are lots of options. It's hard to tell how it will perform in every situation. Besides, client/server technology is new, and we are all still learning."

"Don't blame ,this on client/server," Alex interjected. "Your developers didn't think through the implications of doing multiple database calls over a network. That just won't work well over a telephone line."

"We realize that now," Vinnie admitted. "In the next release, that area is being redesigned to be more efficient."

However, Acme Services couldn't wait for the next release. Their user was a bit annoyed at having to pay for a higher-speed line, but arranged to have the network group upgrade the line.

A few days later, George drove to the customer center to see how things were going. Response time was better, but not as good as hoped for. Instead of waiting 10 to 15 seconds each time a screen was completed, users were only waiting two to three seconds.

However, he was quickly reminded that response time had been much better when they were running transactious on the mainframe.

DON'T FORGET THE OPTIONS

George, Sally and Alex got together and looked over the outline of the system. They reran the snooper and reexamined the performance data. Everything looked fine. They decided it was time to get Vinnie involved again.

"Vinnie, we have looked at each of the components in detail," said Alex. "We've done an upgrade to the line. The only thing we couldn't look at was the PC itself. Just how much of the actual processing is being done by the application on the PC?"

"Actually," Vinnie said, "that depends on the options you selected. George, remember all of the optional services that could be selected when you installed the product? There is a certain amount of overhead for each one you chose. Also, the amount of processing is somewhat dependent on the number of fields filled in on each screen. If all of the options are turned on and all of the fields are entered, there can be a lot of processing. We simply manipulate data with user-defined parameters. Depending on how these are set up, it could be compute-intensive."

"So," George added somewhat sarcastically, "you' re saying we need a bigger box?"

Alex intervened, "Vinnie, they're running 386 machines now. Do they need 486s or more memory?"

Vinnie seized on that. 'I know our developers now use 486s and they all have quite a bit of memory." "Are you telling me that I have to tell my user that she will have to replace these machines with larger ones?" George said angrily.

"Hang on, George," Sally replied. "We may need an upgrade, but have we checked to see if we need all those options? That could make a difference."

"Let's get a list of all the compute-intensive options and turn them off," Alex suggested. "We can then see the impact on response time. This will help us determine whether it is a hardware or software problem."

George shook his head. "Does this mean I can't use many features without a bigger PC? All I know is that we better not need an upgrade."

"George," Sally consoled, "remember, we only purchased five PCs for the pilot. That's only a fraction of what we will eventually need."

George reported what they had learned to his boss, Paula the Pragmatist, who is head of PC development. "Paula, I guess I've learned my lesson about client/server. It took the vendor, a network specialist, a LAN specialist, Sally, Alex and myself several weeks to solve one performance problem. Is this what it's going to be like from now on? If so, we have seriously underestimated the operating and maintenance costs for this system."

He continued, "Now it looks like we will need to upgrade the PCs to 486s,"he added. "I'm not sure if any of our cost/benefit analysis is still valid."

Paula put the problem into perspective. "George, this technology is new for all of us, including the vendor. As frustrating as it has been, we've learned a lot. Besides, with the delays we've experienced, we may be able to get 486 machines for the amount we budgeted for 386s."

She continued, "We can apply what we have learned to the system we are developing in-house, and we may have saved ourselves some costly mistakes. If it's any consolation, your efforts will pay off in the future."l

COPYRIGHT 1992 Wiesner Publications, Inc.
COPYRIGHT 2004 Gale Group