Skip to Content
Author's profile photo Jan Penninkhof

Scalability in the cloud – Caching

/wp-content/uploads/2013/01/low_on_cache_177287.jpgThe SAP Netweaver Cloud Platform is an excellent choice for building applications that should be available outside of your premises for e.g. your customers, suppliers or employees. Instead of having to add a new layer of application servers, reverse proxies and networking/firewall rules, to expose these new applications to the internet, you could also just start building on the SAP Netweaver Cloud platform.

In many scenario’s a connection to your back-end, to both retrieve and update information from e.g. you ERP system is required though. The cloud connector comes in very handy here, as it allows to do this in a secure way.

Reduce the number of hits on your back-end

When you use the cloud connector, you need to be aware of the fact that every time someone knocks on the doors of your application, this will also cause a hit on your ERP system. Especially when the application is a huge success and many users are using it intensively, the number of hits on your ERP system may also increase. On top of that, the back-end system is a “remote” system for a cloud application, so there will always be some lag.

To keep the number of hits within proportions it may be wise to think about caching at an early stage of the development process, so that it will be possible to scale the application quickly when necessary. Especially relatively static information such as e.g. a department lists are very easily cacheable.

The easiest way to achieve caching is to implement http-caching at the client-side. By inserting expiry-information in the header of a http-response, the browser will not hit the server again if the cached data is still valid.

Although this may work in scenario’s in which a limited number of clients generate a lot of traffic, it will be less beneficial in a scenario in which a large number of clients generate a limited amount of traffic. In that scenario it will be better to implement caching within the application to prevent hits on your back-end.

Caching from within your cloud application

When multiple clients need the same information, such as e.g. a department list, it may be a good idea to store the department list somewhere in the application, instead of hitting the back-end system with the same request multiple times. What comes to mind is e.g. a hash-map that is stored in a thread-local or static application-level object. If it’s just a department list, this is probably not such a bad idea, but if the department lists contains multiple attributes about the department as well, this may hit the memory quite badly though. As a department list may also grow in the future, it may be wise to already take precautions and make sure the cache isn’t just a fixed hash map, but a real cache that drops records as soon as too much memory is consumed.

In previous web-based projects, memcached was always my cache of choice, because of it scaling and clustering capabilities. However, memcached is not a java application and can’t be run on the SAP Netweaver Cloud  Platform. To run a cache on the SAP’s Java platform, a Java cache is needed. In the Java world Ehcache is a widely used cache library that can be integrated with your own application. If the need arises if can scale up to a distributed cache, just like memcached.

The nice thing about ehCache as compared to a fixed hash map is the fact that it is highly configurable and allows you to e.g. set the maximum number of elements to keep in cache and how housekeeping should be done, i.e. what cache entry should be removed first when the cache is full.

To use Ehcache, you will have to add some code to the methods that call your back-end:

public V readSomeData(K key)
          Element element;
          if ((element = cache.get(key)) != null) {
                    return element.getValue();
          if (value = readDataFromBackEnd(key)) != null) {
                    cache.put(new Element(key, value));
          return value;

When the method is launched, it will try to search for the data in cache. And if it’s not in cache, it will call the back-end to retrieve the data from there. Once the back-end is returning data, that data is store in cache for future use.

Eager loading

In the scenario of a department list, it may make sense not to wait for a client to retrieve information about a single department and fill the cache lazily, but it may make more sense to pull all departments from the back-end and fill the cache in a more eager way. R/3 usually processes one SELECT resulting in multiple records more efficient than separate SELECT SINGLE calls for each individual record. Ehcache also has a bulk load mode, and is able to process cache writes much faster in this mode.

When cache-refreshes are scheduled to update the cache when it is about to expire, future request would be served straight from cache, which dramatically increases performance and lowers the number of hits on the back-end.

Code cleansing

Complex applications have several different methods to retrieve various information from the back-end. All these methods would need to be modified to implement caching for these methods, while the code pattern that needs to be inserted is almost the same each time. SpringSource has seen that, and has implemented a nice annotation for this, to make your code look better and cleaner.

When you are using Spring and the built-in ehCache bridge, you can use the @cacheable annotation instead of adding logic in the top of a method to check if the resulting value can be retrieved from cache. Please find an example below:

public V readSomeData(K key)
          return readDataFromBackEnd(key);

This example actually does exactly the same as the previous example, but the @Cacheable annotation now takes care of trying to pull the resulting value from cache and pushing it in there when data is pulled from the back-end.

A nice tutorial on how to use this Spring annotation can be found here.

When you are buildling an application, using SAP UI5 as front-end, you will probably be building many REST/JSON services. In that case this tutorial may give you a head-start, applying CXF (to build REST services) and the Spring version of Ehcache to cache back-end data.

Oh, and if you’re going down the path of using the Cacheable annotation from the Spring framework, I highly recommend to Mavenize your project.

Available memory on SAP Netweaver Cloud Platform

The amount of memory assigned to a virtual machine is not unlimited, and to find the optimal cache sizes it may be necessary to do “the math”. Please find a number of key-values/rules-of-thumb below, based on the so-called “Lite” VM:

  • Default number of threads: 200
  • Total amount of memory available per VM: 2GB
  • Amount of memory available for an application: ~1GB, the other 1GB is consumed by your application, the infrastructure (perm size, server itself, your application, SAP UI 5 etc.)
  • Amount of memory available per thread: ~1GB / 200 = ~5MB

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Harald Mueller
      Harald Mueller

      Excellent blog Jan, EHCache is a very good choice. Besides the spring integration it has out of the box integration with hibernate and is incredibly popular and able to scale to the requirements of large enterprises. Of course for big memory and more complex use cases which need querys, aggregation, analytical and/or transactional updates HANA would be the default solution. But that's significantly more than just ca(t)ching up in the cloud.

      Author's profile photo Jan Penninkhof
      Jan Penninkhof

      Thanks for the compliments, Harald. Really appreciated, especially coming from you 🙂

      This blog was actually inspired by  a discussion that I had with Sameer at SAP Code Jam Huizen. In that discussion we went over a couple of the components of SAP Netweaver Platform and the things that I was missing there. This obviously included the caching mechanism that I was used to (memcached) or the possibility to install it.

      During that discussion we also discussed the option of storing cache in a cloud database, local to the SAP Netweaver Cloud Platform, which would imply storing it in MaxDB or HANA.

      This seems to be a good option and is even supported from Ehcache. But we both had our hesitations when we reviewed what the pros and cons. In theory, I do believe spilling over to a HANA (in-memory) database could work perfectly and could instantly become my first choice as a spill-over store, but this idea if though provoking. Please find my (provoked) thoughts below:

      Mosts caches would work by writing key/value-pairs to it. This is the way Ehcache, but also e.g. memcached works. Most columnar stores databases, such as Apache Cassandra work like this as well. Unfortunately, the only way to access HANA, would be to go through the SQL-ish APIs like JDBC and JPA. I'm not sure if such a thing exists for HANA, but it would be great if there were an no-SQL API, similar to e.g. Hector. This would allow a more direct way to access data, to facilitate NoSQL-ish use-cases such as high-performance caches. Translating cache writes into SQL (JDBC/JPA) and then back to columnar data (key/value), sounds to me like like extra plumbing that may have its impact on performance.

      This is making me curious. Do you know if there are any plans to expose a no-SQL API or other more native API  to access HANA in the Cloud?

      Thanks again for your comment Harald!

      Author's profile photo Robert Wetzold
      Robert Wetzold

      Great post Jan! I just ran into the same issue exactly this week and evaluated memcached, EHCache and some more. Memcached is out of the picture as you stated. I then tried EHCache but soon gave up since it has so many dependencies to other components and I was reluctant to include them all "just" for caching.

      I then got across Google Guava Caching. It is a single highly optimized, self-contained library with all the great features like time- or count- based eviction. Just the distribution across several systems is missing. What do you think of it? Do you have any experiences here or can dare to compare both solutions?

      Author's profile photo Jan Penninkhof
      Jan Penninkhof

      Hi Robert,

      As I was building a business app, I was looking for a caching mechanism that would be easy to implement and wouldn't require me to add too much code to my business logic. When I was looking into ways to implement caching, I quite quickly ran into the spring annotations that take care of the caching. I found it an especially powerful approach to use at the connectivity layer of an application. No extra code, just a simple @Cacheable annotation will do. I was so much charmed by this annotation approach, that I basically set support of this annotation as a requirement for the caching library I was going to use.

      I believe that Guava is also moving closer to spring, but as far as I know it doesn't support the @Cacheable annotation yet, which was a deal-breaker for me. Another thing I like much about ehcache is it's scalability. When you want to scale up, it is able to share its cache with other nodes of your application.

      As for the dependencies, I used Maven to take care of that 😉