They can also help in geographically dispersed arrangements. If the
database/main web server is in Atlanta, dropping an accelerator in LA can
help improve performance. In addition to the above mentioned
optimizations, accelerators can also do things like minimize the IP
overhead by aggregating all requests into fewer or even a single
conversation. Example: A web page may be composed of many parts. Images
and scripts are common parts. Displaying a page results in "gets" for each
of those parts. Each get has IP request/confirmation overhead. The LA
accelerator will aggregate those internally & send them to the Atlanta
appliance. The Atlanta appliance will process the gets locally to the
server (eliminating the trans-continental overhead that each get would
result in) and package them up as a single return of data which the LA
appliance breaks apart before sending to the endpoint.
On Fri, Jul 5, 2013 at 3:16 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
We have an internet accelerator. It works more by a compression
feature. My boss says it's great. We use that between plants, etc.
The term "accelerator" may be a bit of a misnomer because inserting
another server into the topology always adds some extra latency to the
line. An accelerator may actually become a decelerator in the case of low
volume web sites. The IBM i Apache server has built-in caching &
compression, for example. You don't need another server for that.
On the other hand, it may make sense to move certain workloads off the
database / application server. Encryption, compression, certificate
management, caching, and serving static content are good examples. The
extra server may provide a buffer against DOS attacks and general hacking.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives