When administrators fall for the latest buzzwords and ideas, things are different. It's all about performance, anything to speed communication up. I agree. I used to be able to read the text files while they downloaded faster than my 300baud modem could pull them from a BBS. Speed is good. $OurBigApp used to take up to 20 seconds to pull up certain screens; we got that down to a norm of 2-3 seconds on a good connection, normally comprising <50KB of data. That's apparently not fast or small enough. Companies with really remote offices have big latency problems, especially when stuck using 1000km of copper to the next CO or connecting via satellite.
Lenny's got latency problems. Serious latency problems. His remote offices ping no better than 450ms and we normally require a max of 250ms. Lenny had an idea:
We research in the internet and run into some vendor's web application acceleration product that cliams it can help to accerate $YourBigApp connections to overcome the network latency.Lenny has no idea about what "web acceleration" is nor how it works, but a few companies are telling him they have it and it works. They're even claiming it works specifically with $OurBigApp. We, on the other hand, don't necessarily agree. Lenny was probably drooling as he filed his ticket.
1. Does web application acceleration techonolgy will befenit connected users to overcome the network latency issue?
2. Are there any vendors products that you certified or recommended to overcome network latency issues.
3. In the case of international link, it is not possible to reduce the latency. What is your recommendation to deal with network latency issue that may cause connected client not working well?
Lenny's got buzzword fever. I figure I might as well answer this one completely and then rewrite it into an FAQ for our Knowledge Base. He oughta be real happy; I'll teach him about this stuff and save him some money
Dear Lenny,Now how much more helpful could I have been?
Claims of functionality by third parties must be backed and proven by them. We don't support them.
Web accelerators work by three basic means: caching, compression and pre-fetch. Caching of images is acceptable but for obvious reasons, caching of the rest of the dynamic application does little good. Most of our images are very small and are already cached by the local browser.
$OurBigApp already allows compression at the server; a compressed file can't be further compressed. Pre-fetch relies on background loading of links or expected next accesses. Theoretically an accelerator could be designed and tuned for $OurBigApp to load certain elements in the background, but the accelerator would have to determine which fields were such elements in the first place. Since the values for a child elements will differ based on the parent, it would be nearly impossible for most fields to be pre-fetched.
Latency is the tough one. You could use the non-rich client for high-latency offices since there's no interim communication between it and the server. You can modify the default application time-out and keep-alive settings as well as those of the Web server.
At the client level, Microsoft provides information on editing TCP/IP registry entries at http://support.microsoft.com/default.aspx?scid=kb;en-us;158474. The time-out and keep-alive settings should be adjusted ; default values and explanations are given on the site.
In my mail this morning was low score notification. Lenny gave me 3s across the board and wrote a long complaint that I hadn't given him an acceptable web acceleration solution.
I write to the monkey asking if $BigNetCo and $OtherNetCo Web accelerators are support and he didn't answer about each one. Then he say accelerator won't work but $BigNetCo and $OtherNetCo say it does! He only give link to Microsoft but they can't fix latency. We need acceleration!My merit-based bonus is taking another hit because of another fuckwit. The only revenge available to me is saving enough money to buy his company's products and then... not buyithem.
There's a poll in the HuSi version.