Network/Wan slow application response

[SR]

Scenario - A company has 10+ remote sites. Each site has a server for misc documents. At 1 remote they have a client/server app (poorly written and takes a fair amount of bandwidth) housed their which the entire company accesses. The bulk of the traffic on the wan is telnet to a mainframe, internet/email, and the client/server app. Each remote on average has 10 users. 3-4 use the client/server app. Users report that it takes 10-15 minutes to load the cleint/server app. The wan is comprised of frame relay. Most remotes have 768k cir but 2 have 56k. The site hosting the client/server app has 56k. The headend only has a T-1 port. (Note: I had no involvement in creating this pile)

What would you do to improve this network and why?
Requirements - must be phased in and can use the following citrix, new routing equipemnt, and higher frame relay circuits.

 

[SrASpeedRacer]

Unless you have the money to spend on upgrading each circuit $$$$ :Q

I would look into Packet Shapers.
We just Installed Packeteer Packet Shapers but they are not online yet.
They are supposed to manage the bandwidth by giving different protocols different bandwidths. You can section of the bandwidth in many different ways but that's how we are setting them up. They also condition the packets and are able to get more utilization out of your connection.
I don't know to much about them but if you want to read about them go to Packeteer

Will

PACKETEER'S® PACKETSHAPER® NAMED NETWORK COMPUTING'S EDITOR'S CHOICE

CUPERTINO, Calif. - December 9, 2002 - Packeteer®, Inc. (NASDAQ: PKTR), a leading provider of application-intelligent traffic management systems, today announced that its PacketShaper 4500 had been named "Editor's Choice" in a comparative review entitled "Warding Off WAN Gridlock" published in the November 15 issue of Network Computing Magazine. PacketShaper was chosen over products from Allot Communications and others as the best product to monitor and manage wide area network traffic.

"WAN bandwidth is expensive, but when congestion occurs, some administrators simply throw cash at the situation," writer Michael J. DeMaria noted in the review. "This approach, however, doesn't address the underlying problem. Until you gain granular control over the way packets are prioritized, you'll be playing a zero-sum game, with users gobbling up your pricey bandwidth as fast as you bring it online. Moreover, as latency-sensitive applications, such as VoIP and videoconferencing, become more common and have to contend with FTP and P2P traffic for throughput, even fat pipes won't guarantee QoS."

"We gave Packeteer's product our Editor's Choice award for its granularity in setting policies, impressive classification engine, and intuitive user interface," continued DeMaria.

 

[Scarpozzi]

I think you pretty much nailed it when you said you can upgrade your equipment and use Citrix. I suggest just stepping up to a 802.3 standards internally and running Citrix...if you have the means. It's a very big project because users may take some time getting used to the change (Citrix training). Also keep in mind that you'll need a Microsoft CAL to match each Citrix license....it may be costly if you expand, but the performance is great. The 2, 56k connections may need to be bumped to broadband because citrix is really slow over modem, but will work.


For some temporary help on the Frame Relay stuff. I would think you may have an issue of Admission Control going on. Congestion control on those networks won't admit users to connect if the resources aren't available. If the users with the faster connections are using up a lot of bandwidth and the connection is bad (dropping packets) it could exponentially eat up your connection and then block additional users from connecting until the resources are free.

 

[mboy]

Well, it looks like the major bottle neck would be the site hosting the client/server app that is only 56k, no?

 

[Garion]

Lessee.. Client/server apps are usually very network efficient, since the server does most of the grunt work of searching the data, but this one says it's badly written. Depending on the amount of traffic in the queries, Citrix might or might not be useful. If users print a lot of their work in this app, Citrix would probably *not* be an improvement, since printing is printing - Yes, I'm sure Citrix compresses the jobs, but probably adds little bang-for-the-buck, especially considering the very high cost of a Citrix server. Citrix is primarily used in fat client apps where the client has to do the bulk of the work searching for data - Things that require a mapped drive letter. Depending on how badly it's written, probably not recommended.

In any case, Citrix needs about 25-30Kb/s per user. With a 56K line, you'd get *two* happy users. Probably not ideal.

Sounds like what you to recommend is one of two things. Either move the server to the site with the T1 or upgrade the bandwidth to what you need. If you go Citrix, figure 30Kb/s per concurrent user, plus ~40% overhead for the rest of the office, depending on how big it is.

Two things immediately come to mind.

1: You really don't have anywhere near the amount of data you need to do a really good job on this. You would need to profile the application in detail to determine exactly how much bandwidth it needs on a per-concurrent-user basis. Figure out how much bandwidth this will take, and compare the cost of bandwidth to the cost of the Citrix server and supporting it (which is considerable). Make sure to calculate it over the cost of the estimated life of the application before it will be replaced or re-written to be more efficient.

2: This sounds suspiciously like a class assignment. Not that I mind, but I'd be amazed to find out that a real-world business has screwed things up *this* much. Profs tend to have creative imaginations for this kind of thing. Of course, truth is often stranger than fiction..

- G

 

[SR]

Garion this is truly a real world situation. You'll see the note saying I had nothing to do in creating this pile of a network. Anyhow at my company I primarily do lan/wan/voip and some server work. The company I work for was brought in to *fix* this network.

Well first off, SrASpeedRacer, no amount of packet shaping with the current wan will do anything for this customer and as for admission control, I don't thing gatekeepers woudd help anything but throw $40k at something that should be very obivious which is not enough bandwidth. Citrix actually takes 10-20k per session excluding printing.

Anyhow this is how I wanted to handle the phased in appoach to the network.
First, install a 3 T-1 atm ima and reduce the branch frame relay to 256k to 768k depending on exact # of users. The sum of all remote cir's will still be greater than the 4 1/2 meg ima group. Plus move the client/server app to the main location. This should reduce the load time to more acceptable load times. I'd implement Qos for the app until citrix was brought online. I estimate it would cut the time from 10-15 minutes to 2-4 minutes and printing would still be local.
Next we'd bring in citrix for core apps management and reduce bandwidth consumption from the client/server app.

Reasoning: First off the biggest bang for the buck (non reoccuring costs) is in reconstructing the wan. Implementing citrix into a wan where the headend port is oversubscribed 5 1/2 to 1 (11 remotes at 768k, 2 at 32k) is trouble. The current routing gear is true garbage and no qos can be setup on them. Assuming 8 users at 10-20k per session at each site is 80-160k without overhead per site which I just made printing a new problem. Prints jobs may take up to 5 minutes to print. Citrix will reduce the app load time but more than likely will still take 2-3 minutes.


Can you see a reason why you would want to install citrix first then reconstruct the wan?