Skip to main content

What's everyone using for Max in a WAN enviornment? We're getting way-too-slow reponse time (4 min to open a 1900 record database!)using the regular Internet with a VPN and cable modems either end (bandwidth averages 640kbps). For our 10 users, cross-country Maximizer WAN recommendations have included Microsoft Terminal Services, PC Anywhere, etc.

So what are you using? What was good/bad/indifferent about the solution? What would you do if you were starting from fresh?

Just taking a poll - but the results whould be of interest to most of us.

Thanx for your feedback - R.
Original Post

Replies sorted oldest to newest

Maximizer shouldn't really be run over a WAN connection (this is my own personal opinion) in its standard form as it is Client Server application designed for ideally 10/100Mb LANs

The Pervasive engine that is the underlying foundation of Maximizer is a Transactional Engine

Technically The TCP/IP protocol which is being run over a LAN and a WAN, like other protocols, has a number of built-in limitations. How these limitations affect your application depend on whether it is a transactional or streaming application.

Transactional applications are affected by the overhead required for connection establishment and termination. For example, each time a connection is established on an Ethernet network, three packets of about 60 bytes each must be sent and approximately 1 RTT (Round Trip Time) is required for this exchange. When termination of a connection occurs, four packets are exchanged. This is compounded when an application opens and closes connections often, which Maximizer in all its wisdom does do.

In addition, when a connection is established, “slow-start” takes place. This artificially limits the number of data segments that can be sent before acknowledgement of those segments is received, an efficiency designed to limit network congestion.

When a connection over Ethernet is first established, regardless of the receiver’s window size, a 4-kilobyte (KB) transmission can take up to 3-4 RTT due to slow-start.

A TCP/IP optimization, known as the Nagle Algorithm, can also limit data transfer speed on a connection. The Nagle algorithm was designed to reduce protocol overhead for applications that send small amounts of data, such as a Telnet session sending a single character at a time. Rather than immediately sending a packet with lots of header files and little data, the stack waits for more data from the application or an acknowledgement before proceeding.

Delayed acknowledgements or “Delayed Ack” was also designed into TCP/IP to enable more efficient “piggybacking” of acknowledgements when return data was forthcoming from the receiving side application. However, if this data is not forthcoming and the sending side is waiting for an acknowledgement, delays of about 200 ms+ per-send can be experienced.

When a TCP connection is closed, the connection resources at the node that initiated the close are put into a wait state, called TIME-WAIT, to guard against data corruption if duplicate packets linger in the network (ensuring both ends are done with the connection). This can deplete resources required per-connection (RAM and Ports) when applications frequently open and close connections.

In addition to being affected by delayed ACK and other congestion avoidance schemes, streaming applications can also be affected by a default receive window that is too small on the receiving end.

Add to all this the potential Latency issues with the majority of WANs.

In a network, latency, a synonym for delay, is an expression of how much time it takes for a packet of data to get from one designated point to another. In some usages, latency is measured by sending a packet that is returned to the sender and the round-trip time is considered the latency.

The latency assumption seems to be that data should be transmitted instantly between one point and another (that is, with no delay at all). The contributors to network latency include:

Propagation: This is simply the time it takes for a packet to travel between one place and another at the speed of light.

Transmission: The medium itself (whether optical fiber, wireless, or some other) introduces some delay. The size of the packet introduces delay in a round trip since a larger packet will take longer to receive and return than a short one.

Router and other processing: Each gateway node takes time to examine and possibly change the header in a packet (for example, changing the hop count in the time-to-live field) the amount of gateways involved can be tested with a simple 'TRACERT' to test the hops.

Other computer and storage delays: Within networks at each end of the journey, a packet may be subject to storage and hard disk access delays at intermediate devices such as switches and bridges. (In backbone statistics, however, this kind of latency is probably not considered.)
2) In a computer system, latency is often used to mean any delay or waiting that increases real or perceived response time beyond the response time desired. Specific contributors to computer latency include mismatches in data speed between the microprocessor and input/output devices and inadequate data buffers.

good tools to test the response times in these situations are AnalogX's Netstat Live and Sysinternals TCPview.

The best solution in this situation is to implement Terminal Services or Citrix, however please note this particular solution is still not supported by the software manufacturers

With a Terminal Server or Citrix configuration the Server at base stores all data and carries out all the processing, sending just moniter display changes (GUI interpretations) using a Protocol such as RDP (terminal server) or ICA (Citrix) over TCP/IP to a Dumb terminal or Thin Client thus reducing the amount of Bandwidth sapping Client/Server transactions 50 fold

Hope this helps

Regards
Maxtalk Administrator

(excerpts of this posting were sourced from WhatIs.com)

[This message was edited by CABC Support on April 29, 2003 at 02:35 PM.]
Last edited {1}
We all know that Windows 2000 terminal services has been around for years now, and is an excellent solution for many businesses, both small and large. Now with even more improved terminal services in Windows Server 2003 there are a lot more reasons to move to a terminal server environment, even for small businesses.

To this end, why isn't Maximizer testing and supporting their product on Windows terminal services? I would think it would give a competitive edge, and database applications are perfect for terminal services because of the huge advantage of local disk access vs. LAN/WAN access.

Two of my clients are planning on moving to terminal services, and if Maximizer can't provide support we'll move to a competing product. The TCO benefits of terminal services are just too good.
Unless you have a super bandwidth line like a T3 or better you will not be able to run Maximizer Reliably through a LAN. You can use Terminal Server although the technology neccessary for large number of clients is very pricey.

You best bet is to use MaxExchange and use your WAN to do the synchronizations, since SP 2 for MaxExchange we have had very few problems and since SP 3 (only been a few days) we have had zero problems with MaxExchange.

Add Reply

Post
LEGAL INFO
CONTACT US
Copyright 2007-2018 Advoco Solutions Ltd. All Rights Reserved.
×
×
×
×
Link copied to your clipboard.
×