Has this ever happened to you? You’ve implemented a new SAP solution or developed a custom application and, with a few iterations, you’ve tuned performance and functionality. Your test users are happy with what they see, so you roll out the application to the relevant target users in your company, wherever they may be located. But now, the users in remote locations are complaining about poor user experience because of long response times. Why are they experiencing a delay after everything worked fine during the initial tests?
In global scenarios, we often see longer response times because wide area network (WAN) effects add up. WAN effects include:
- Limited bandwidth. The amount of data that can be carried from one point to another in a given time period is restricted.
- High latency. As the distance between the user and the application increases, it takes more time for a data packet to travel from the user to the application and back.
- Overall congestion. The information overflow exceeds the network capacity during peak times.
- Packet loss. Some transmitted data packets do not arrive at their destination, causing delays because they have to be re-sent.
These effects become especially significant for Web-based applications — applications you can address via HTTP and HTTPS. Historically those protocols were designed for displaying static content rather than for dynamic applications. Many state-of-the-art HTTP applications come with rich-client-like behavior; while this behavior offers better accessibility and a unified look and feel, it may negatively affect performance.
In an SAP environment, SAP-centric scenarios — such as Web-based SAP Business Suite applications, SAP NetWeaver Business Warehouse (SAP NetWeaver BW), and SAP NetWeaver Portal — may suffer from WAN effects. In extreme cases, WAN effects may make certain applications unusable remotely and endanger a global rollout of business-critical functionality. So how can you tackle WAN challenges, provide worldwide users with access to central SAP applications, and achieve better performance?
Address Global Performance with AccAD
SAP offers accelerated application delivery for SAP NetWeaver (AccAD), a complementary standalone offering that virtually moves applications closer to end users.1 AccAD significantly reduces the WAN overhead in response times, allowing you to achieve a satisfying usser experience even for remote locations.
SAP first released AccAD to market in the summer of 2008; since December 2008 it has been available in unrestricted shipment. The latest version is AccAD 2.1.
AccAD is a symmetrical solution — you set up one component (the Server Front-End) close to the applications and another one (the Client Front-End) close to the users (see Figure 1). Between the two components, the Web-based traffic is optimized with efficient caching and compression mechanisms, with a special focus on SAP-centric scenarios. Caching allows static data to be delivered directly from a Web cache to the user. AccAD’s compression algorithms reduce the transmitted data stream in the WAN 10 to 20 times more than generic browser compression, thereby optimizing the usage of the network’s bandwidth to transmit more information.
||A symmetrical landscape is the basis of accelerated application delivery
Between the AccAD components, a persistent tunnel with 16 parallel TCP connections is established. This tunnel does not require the connection from a browser to an application server over the WAN to be opened and closed for every interaction, and the tunnel is almost fully resistant to packet loss. Moreover, requests and responses can be transmitted in parallel through the tunnel.
As a result of using AccAD, you’ll experience faster data transmission, which leads to increased productivity — global users can work more efficiently when AccAD is in place (see sidebar). Consider, for example, a user in Singapore who wants to download an SAP NetWeaver BW report housed on a server in Boston. With AccAD, the user can access the report in seconds rather than minutes, allowing him to work more quickly and without becoming frustrated by significant lag time — all without having to do anything differently on his end. Plus, you don’t have to do anything differently on the application side either. You just change the communication path between the user and the application, while leaving the actual user and application untouched.
AccAD also provides stable connectivity between the application and the users, reducing connection terminations and packet loss. You can cost-effectively centralize your systems and applications and provide reliable connections to remote locations through AccAD.
How AccAD Combats Network Effects: A Real-World Analogy
To better understand the effects that WAN overhead can have on performance and response time — and to crystallize how AccAD can counter them — I’d like to offer an analogy from our daily life: transporting goods via highways.
Let’s say that you own a consumer products company with its headquarters in New York City (see Figure 2). When your company’s Los Angeles subsidiary requests certain goods from headquarters, a truck drives from Los Angeles to New York City, collects the goods, and carries them back to Los Angeles. What factors would influence this delivery?
- The truck’s travel time (latency). This calculation depends on the route’s overall distance, its maximum speed limits along the way, and the number of intersections and traffic lights.
- The available capacity on the streets (bandwidth). Fewer lanes mean fewer vehicles can drive on the road.
- Traffic (congestion). If the road’s volume is overreached, traffic jams slow the overall travel speed.
- Collisions or accidents (packet loss). If the truck is hit in an accident, goods may be lost and will have to be shipped again.
||Adding a symmetrical solution can improve delivery times between a company’s headquarters and its subsidiary — a useful analogy for how AccAD streamlines network performance
How could you improve the travel conditions between New York City and Los Angeles? You can introduce a symmetrical solution by establishing a parcel station and a depot to optimize the delivery time (refer again to Figure 2):
- First, you can transport just the goods themselves. By removing unnecessary packaging material, you can condense the goods to use less space in the truck. And by optimizing how the items are packed, you can ship more items in one trip. (AccAD analogy: the efficient compression mechanisms)
- You can also cache goods closer to the subsidiary. At the local depot near Los Angeles, you can stock goods that the subsidiary frequently requests — these items are “static.” Thus, a truck doesn’t have to travel to New York City and back each time the subsidiary requests goods. (AccAD analogy: the Web cache in the Client Front-End)
- Next, you can optimize protocol by using an established tunnel — you can set a fixed route between the two locations so you won’t have to check the route each time the subsidiary requests an item. An optimal route has few detours or construction sites. For this predetermined path, you can then optimize the size of your trucks and the amount of goods that are loaded on them, considering factors such as the height of bridges and the maximum weight allowed on the roads, so you can minimize freight loss and maximize throughput. (AccAD analogy: the persistent tunnel)
- The symmetrical solution also allows you to offload the headquarters because the depot can serve a large portion of the demand locally. The parcel station near the headquarters can handle packaging and transporting the goods, freeing up the headquarters to focus on its real job — generating and providing goods. (AccAD analogy: the offloading effects on the application server)
In this analogy, you are streamlining how the goods are packaged and delivered to the subsidiary (the end user), similar to how AccAD compresses and caches data and delivers it through a persistent tunnel. This simple analogy can be a helpful one to share with your deci
sion makers to build a business case for adopting AccAD.
Getting Started with AccAD
Once you’ve decided to move forward with AccAD, we generally recommend that you start with a proof of concept. Here, you can glean insights into performance improvements and how best to integrate AccAD into your company’s existing IT architecture. For your first project, it’s best to choose an application and a remote location where you see an immediate need for the implementation — and where you expect to see a substantial business benefit.
An essential part of the process is to measure the performance of the applications locally and in the WAN, both with and without AccAD. Usually it only takes a few weeks to run this initial project, and the results will likely speak for themselves, prompting you to globally roll out the solution to other sites that are experiencing performance issues.
Experience has shown that the WAN overhead in response times could be reduced on average by two-thirds. Note, however, that the potential for response time optimization with AccAD depends on various questions unique to your business, such as:
- For which application do you want to optimize user access? If an application repeatedly communicates back and forth between a user’s browse
r and the data server and transmits large chunks of data, that application will likely suffer greater WAN effects than an application that bundles a user request. You’ll see greater improvement using AccAD with the former application.
- What are your network conditions? AccAD only addresses the overhead a user encounters through global access. The more challenging the network conditions are — for example, the farther a user is from a server — the better results you will achieve using AccAD.
- What does your internal Web infrastructure look like? Your IT environment will affect how you choose to integrate AccAD into your landscape. You’ll need to decide how and where to place proxies and load balancers, and how to secure the communication from the application through the AccAD components to the end user. Other components that are present in the landscape will influence how you integrate the solution.
AccAD is an easy, effective solution for companies that suffer from bandwidth- and latency-related performance issues. By reducing the WAN overhead in response times, AccAD helps you achieve a satisfying user experience, even for employees working in remote locations.
Visit http://sdn.sap.com/irj/sdn/nw-accad for more information about AccAD. If you’re experiencing slow response times or poor performance, I encourage you to speak with your SAP consultant or account executive about this solution.
Jana Richter (firstname.lastname@example.org) works in SAP NetWeaver Product Management in Walldorf, Germany. She joined SAP seven years ago and since 2008 has focused on accelerated application delivery for SAP NetWeaver. Previously, she was responsible for the portal capabilities of SAP NetWeaver.
1 For optimal performance, make sure you have tuned the application itself. See Susanne Janssen’s “Consolidating to a Single Global Instance?” article in the January-March 2009 issue of SAP Insider. [back]