Network Considerations

Clients connect to the application over the network. The application also communicates with its various parts (application server, database, report server) over the network. If any segment of the network performs poorly, the end user experiences a system that is slow and hard to navigate.

TRIRIGA® is a web-based product that operates on a request and response basis. If the requests and responses are delivered slowly, TRIRIGA has no control over response time. If end users are complaining that TRIRIGA overall "feels slow," as opposed to one particular process being slow, the network is often the root cause and should be investigated first.

Sometimes, it is necessary to understand the network speed throughput from different client locations. This can be a very hard task to accomplish in a timely manner if you must involve the network administration team. In the IBM® TRIRIGA Administrator Console, the Performance Monitor manager has a way to help you test different client locations and compare network speed throughputs. The network Speed Throughput Test link tests the network speed from the server to the current user desktop. In the results, you can see your speed throughput in kilobytes, and then an average comparison with other network structures. Information about upload and download speeds, speed to generate the data, and speed to upload and download to the database are included.

The network Speed Throughput Test link can be provided to client end users without the need for a login. For adequate response times, users should be able to obtain network throughput of at least 229 kilobytes. Users may begin to experience performance degradation if the network does not operate within these parameters. At this point, network traffic speed from that client to the server should be investigated by a network engineer or IT administrator. It is also helpful to have the client test hitting the TRIRIGA server directly, circumventing any web servers and proxies, to confirm if the speed improves. In many cases, one or a combination of intermediary proxies contributes to poor network speeds.

For example, if TRIRIGA is deployed to WebSphere Application Server Liberty on port 9080, the direct URL removing redirects, proxies, load balancers, web servers, firewalls and more might be: http://[websphereserver.com]:9080/

Network Speed Throughput Test

Some options for resolving low-bandwidth or high-latency network performance issues include services such as Windows Terminal Server and Citrix. These services can help provide maximum performance between the Windows Terminal Server or the Citrix client and the application server with a minimum of traffic between the Windows Terminal Server or the Citrix server and the end user.

A benefit of running TRIRIGA through Citrix is that Citrix traffic is treated as "business traffic". In some customer environments, business traffic can take priority over non-business traffic. Some customers have found considerable improvements in network performance when they use a Citrix or Windows Terminal Server. But IBM does not test or certify Citrix or other bandwidth tools.

You can use network caching, acceleration, and compression utilities to improve network performance.

Sites that have bandwidth or latency issues can use one of the following techniques to improve performance:

• HTTP compression
• Hardware compression

Each of these compression options is mutually exclusive of the other. That is, if you are using hardware compression, then you should not also use HTTP.

2.3.1 HTTP Compression

HTTP compression is a capability that can be built into web servers, such as IBM HTTP Server (IHS) and Apache HTTP Server (AHS) 2.x and above, and web browsers to make better use of available bandwidth, and to provide faster transmission speeds. HTTP compression affects all servers in a cluster. HTTP data is compressed before it is sent from the server. Note that hardware load balancers that bypass the HTTP Server cannot employ this method.

Compression-compliant browsers announce, to the server, what compression methods the browser supports, so the server can provide the compressed data in the correct format. Browsers that do not support compression simply download uncompressed data. Data can be compressed by using a compression module such as Apache’s mod_deflate. The compression scenario is dictated by what the server software supports.

The following compression scenario has been tested and found to be a good solution for low-bandwidth locations:

• IBM HTTP Server: Use Apache mod_deflate and set DeflateCompressionLevel to 3 to improve response time in environments that have low bandwidth and high latency. For information about configuring mod_deflate, see Apache Module mod_deflate.

2.3.2 Hardware Compression Using Network Appliances

Network appliances, such as Juniper and Riverbed, provide compression and caching features. Network appliances can help compress data and optimize bandwidth. Customers report that network appliances can prove to be beneficial to system performance, especially in a high-latency and/or a low-bandwidth environment.

Hardware compression affects all servers in the configuration.