Skip to Content

Over the years, it has become very convenient to address Wide Area Network (WAN) performance issues with Citrix terminal server. Actually it is indeed an effective solution to accelerate access to normal applications (Web and non-Web); furthermore it is easy to setup and deploy. However when it comes to accelerating complex Web applications such as SAP CRM and WebDynpro applications, it may not be the case.

 

In the last few years I worked with a few customers whose global users suffered from WAN performance issues. As a quick-and-easy remedy, they implemented a Citrix terminal server for their remote users. Soon after a good number of users were working via the Citrix server, their screens started to hang. A quick analysis revealed that the CPUs on the Citrix box were fully occupied by the Web Browsers accessing SAP applications, such as CRM, custom WebDynpro Java applications, etc.

 

To put the web browser CPU consumption into perspective, let’s take a look at how much CPU time UI rendering and Javacript execution can take. Recently I have made a few measurements at a CRM customer, where a typical click (which runs in a WebGui) takes 4.061 seconds to finish; however the actual request/response transfer only takes 169ms in total. In the rest 3.9 seconds, the CPU is busy with UI rendering and Javascript execution. This may not be a big problem if the CRM system is directly accessed from the end user’s workstation. However when all the end users are working on the same Citrix server, it becomes a major issue. Adding CPUs to the system doesn’t seem to be a wise solution, as we often expect hundreds of users on the Citrix servers (and you won’t usually have hurdreds of CPU cores on the Citrix boxes due to cost reasons).

 

On the other hand, if we deploy a WAN acceleration solution such as SAP NetWeaver Accelerated Application Delivery (AccAD), the CPU load (by web browsers) will be evenly distributed to many end users’ workstations, which makes it a more scalable solution. By the way, for remote users who can’t even access Citrix terminal server with acceptable performance due to high network latency and low network throughput, AccAD would still provide a decent user experience for them.

 

The underlying problem is, with the current Web technologies, web pages often become very heavy for web browsers to render and execute, especially when you implement complex business transactions with rich user interface in those web pages. Due to the nature of SAP business applications, many of them fall into this case. Therefore in a SAP-centric scenario, it makes sense to choose a WAN acceleration solution (such as AccAD) to accelerate WAN traffic over Citrix terminal service.

 

This fundamental problem with Web technologies is now being worked on by major Web Browser vendors. Microsoft Internet Explorer 9 will provide hardware acceleration for UI rendering (which significantly offloads CPU) and introduce a new Javascript engine that supports parallel execution on multi-core CPUs (see more details here). With AccAD, users can take advantage of those significant performance enhancements once they move to the new browser versions; however Citrix users won’t get too much benefit out of those enhancements because:

1) Normally hardware acceleration for UI can only happen when the user is connected to the console session of Windows, not when they are logged on to terminal sessions* (*this may change in the future with Microsoft RemoteFX technology).

2) Parallel execution of Javascript will not alleviate the overall CPU shortage on Citrix terminal server, as there are not many idle CPU cores left when the above-mentioned high CPU issue happens. 

 

In a word, if you are trying to accelerate Web access to your SAP systems over WAN, it is more advisable to consider a WAN acceleration solution, such as SAP AccAD, especially if you have a large number of remote users. The high CPU consumption on the Citrix terminal server box would defeat the purpose of setting it up.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Simon Kemp
    Hi and thanks for this blog. I was just wondering about costs… Is their an additional license for using AccAD from SAP?

    I also wonder about AccAD as it can only be used for internal scenarios since you need to place a server close to the users… right? If your users are spread across the globe then positioning the AccAD servers may be a challenge or not?

    I have also heard of companies using Akamai and  seeing great performance improvements.

    Again thanks for the blog.
    Simon

    (0) 
    1. Daniel Da Vinci
      Hi Simon,

      Currently AccAD is free with a valid NetWeaver license. There was discussion that this may change in the future but I am not aware of it so far.

      Correct, AccAD requires a CFE (client site) and SFE (Data center site) making it a point to point solution that does indeed bring up the infrastructure and maintenance cost amongst other things.

      AccAD isn’t an automatic selection for optimizing SAP solutions rather something that (amongst other important elements) depends on the WAN structure and user distribution in the landscape.

      Regards
      Daniel

      (0) 
    2. Dong Pan Post author
      Hi Simon,

      Thanks for your comments.

      AccAD is complimentary if you have got a NetWeaver Full Use license. For details please see the AccAD FAQ at /docs/DOC-7706#section5.

      It is possible to use AccAD in Internet scenarios as well. Of course you won’t deploy an AccAD CFE at each city in the world, but you can take a “cascaded approach”, i.e. users in the nearby locations can share one AccAD CFE. For example, you may be able to use one single CFE for all users in eastern Australia. A more important problem with Internet deployment of AccAD is the traffic redirection mechanism, i.e. how to transparently direct users to their closest AccAD CFE. You would need to have a carefully designed mechanism, e.g. a Global DNS solution, to make it work.

      To my knowledge Akamai solutions are great in:
      – route optimization (IP level)
      AccAD optimizes the traffic from TCP level to application level. Therefore AccAD and solutions like Akamai, in this sense, are complementing solutions rather than competing solutions.

      – smart replication of content over the world
      However the content from typical SAP business applications are usually dynamic content that can’t be easily cached/replicated statically. AccAD would certainly do a better job here, as it knows the “SAP application protocol”, i.e., when and how dynamic contents can be cached.

      Cheers,
      Dong

      (0) 
      1. Richard Yarde

        Hello Dong,

        Nice blog, I have known about AccaD for sometime now and working on the Portal for many years. Most of the concerns about the portal was always performance (especially in Global Projects) I know of it’s capabilities in that in SAP SLO and Portal ACCaD has been optimized out of the box, I believe it should be used as a main hub serving continents (so the transfer of data is not so long). The main problem I see is ‘Getting the message out there’. It’s free and can overcome network performance issues’.

        Thanks

        Richard

        (0) 

Leave a Reply