The product ships data a network between the clients and the various components of the architecture. This section outlines some of the practices to optimize the network elements of a configuration.
Network bandwidth
One of the most common questions asked about the product is the network footprint of the Oracle Utilities Application Framework based product. This question is difficult to answer precisely for a number of reasons:
• The amount of data sent up and down the network is dependent on how much change is done by an individual user at the front end of the product. Only the elements changed by the end user are transmitted back to the server. The more the user changes the more the data is transmitted. Given the numerous possible permutations and combinations for data changes at any given time, this can be hard to estimate.
• The Oracle Utilities Application Framework supports partial object faulting. This means the framework only sends data to the client that is being displayed. In screen with more than one tab, the framework only sends the data for the tabs that are accessed by the end user. This
means only part of the overall object required by the screen. Most users tend to operate on a small number of tabs but this can vary from transaction to transaction.
• All transmission between the client and server are compressed using HTTP 1.1 natively supported compression. This can reduce the actual size of the data transmission considerably depending on the content of the changes.
• Screen data is cached on the client machine that can be reused. The product takes advantage of the caching facilities in the HTTP 1.1 protocol and the browser caching functionality. For example, screen definitions and graphics are stored on the client machine to reduce network footprint. Upon every transmission of a screen element the data in the cache is tagged with an expiry date to indicate the life of the element in the cache. Use of client side caching can reduce the network traffic considerably with some customers reporting up to 90% reduction in network traffic when this caching is enabled.
To provide an estimate for the network footprint, the range between 10-200k, on average, per transaction is quoted to adequately cover all the aspects outlined above. This value has been based upon experiences with customers.
It is possible to track network bandwidth using a log analyzer against the W3C standard
access.log produced by your Web Application Server. Refer to the Performance Troubleshooting
Guides for more information about this log.
Ensure legitimate Network Traffic
One of the major factors on performance is the amount of legitimate traffic on the network. The traffic
to and from product shares the bandwidth with all other traffic on the network. If there is any network congestion than all transactions from all network-based applications will be adversely affected.
Some customer sites have found that traffic that is not legitimate can adversely affect network
performance. Traffic that is considered not legitimate includes:
• Traffic generated from viruses and Trojans – There are a plentiful number of viruses and Trojans in the general Internet network that can cause bandwidth issues. Most sites have regular virus protection to minimize the impact to your network but not all. While it is not a requirement within product to have such protection, the industry in general recognizes the need for such protection.
• Unauthorized large transfers – Large transfers of data can adversely affect performance as
it can soak up bandwidth if the transfer is not configured correctly. There have been instances of large FTP transfers slowing down traffic on lower bandwidth networks.
Ensuring that only legitimate traffic is on a network can provide greater bandwidth for all applications (including product) and improve consistency.
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 greatest impact on performance is inconsistency 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). This is a common cause of network latency.
• 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.
Minimizing latency or latest ensuring consistent latency is the goal of most of the product sites. A discussion of latency and how to measure it is contained in the whitepaper Performance Troubleshooting Guide