UP your application using Hazelcast
Perhaps the following situation has already happened to you: when you access a page to fill out a form, you end up giving up on completing it until the end. Filling out several fields on a single web form is a bit tedious, but worse than suffering from boredom, you lack patience when trying to load a field like the list of cities or neighborhoods. This is a good example of the possibility of using a cache in a web application.
With so many options to add cache to your application, which one is ideal? Redis, Memcached, Hazelcast, Guava Cache or a simple java.util.Map? It is a difficult answer, but what I think is important is to use one of the solutions.
Here at Sinch we use Redis and Hazelcast, but we have other cache solutions as well. I’ll tell you now how we use Hazelcast, so you can better understand how it works.
Feel that there comes the story …
To explain Hazelcast, I like to tell a story about its use in one of our applications, let’s go to the details:
Apolo is one of our systems that allows partners to subscribe users to our products. The first version only had one server.
In the subscription flow, upon receiving a request, some extra information was retrieved from our database before proceeding with the subscription.
For the first version, everything worked smoothly, even accessing the database with each request. The number of requests was low, so the solution was meeting perfectly.
Thinking about the solution, we saw the possibility of improving this architecture, especially after the increase in the number of requests.
A new proposal was created, now we have added a simple cache solution, a java.util.Map, where some data was stored in this Map to prevent access to the database.
Until that moment everything worked beautifully! The response time has improved and we found a solution to deal with the large number of requests, but not!
The requests increased and at Sinch we always have a server as a backup, to be safe in case one of them presents a problem.
Problem solved? No, precisely because of the cache solution. If a request was for the first server, the cache data would be stored only for the first server.
If another request with the same params went to the second server, it would again need to go to the database and store it in a separate cache.
Another problem would be with regard to the lifetime of the data in the cache solution, how would it be expired? Only when the server was restarted? Create an endpoint to clear all data from the cache?
It was in this scenario that Hazelcast entered
Hazelcast is a Java-based open source distributed cache solution.
In the case of Apolo it worked very well, as it runs embedded in the application and allows the creation of a cluster between the various servers, that is, the cache stored by server1 will be shared with any of Apolo’s servers in the next requests.
Another detail: if one of the servers restarts for some maintenance, when it returns, it is automatically added to the cluster and will also start using the cache data already stored by the other servers.
More details of the Hazelcast
Among the several possible configurations in Hazelcast, for me, the ones that stand out the most are:
* Possibility to create specific configurations for each group of information that will be stored in the cache (MapConfig)
* Maximum size of records in the cache (max-size)
* Records exclusion policy (eviction-policy)
— LRU: Least Recently Used — Less recently used
— LFU: Least Frequently Used — Less frequently used
— NONE: Ignore the maximum size setting
* Lifetime (time-to-live-seconds) of each element within the cache
* Maximum waiting time (max-idle-seconds)
With these small adjustments it is possible to define rules for each MapConfig structure.
As Hazelcast works embedded in the application, there is no need for a second server or to start another service. When uploading the application, Hazelcast will be ready and active to cache the data.
Other caching solutions like Redis or Memcached, a new service will need to be started on the same server as your application or on some other server. In addition, the application will need to control if access to Redis or Memcached is unavailable.
Final considerations
The use of cache in applications allows a better time in the responses of requests that involve access to the database.
Another point worth mentioning is that there is no perfect solution, Hazelcast, Redis, Memcached, they all have their characteristics and the ideal thing is for you to know which one will best meet the need for your application.
We show how it was possible to improve the performance of Apolo’s response with the use of a cache solution, Hazelcast. In addition to a better time, it was possible to keep the same cache data on all servers forming a cluster.
A second point is the management of each item stored in the cache, with different settings for each group of information stored (MapConfig).
