Mission: Cache
| ID | Short Name |
|---|---|
|
|
This use case demonstrates how to use a cache to increase the response time of applications.
This mission covers:
-
The deployment of a cache on OpenShift
-
How applications leverage this cache service
A developer is implementing a microservice relying on another microservice outside of her “jurisdiction”. This second microservice (CuteNameService) does not respond to request in a timely fashion due to the heavy computation required to compute a Cute Name. To improve the response time of the microservice, the developer decides to store the last response in the cache (for a few seconds) avoiding the calls to the CuteNameService. Her microservice immediately sees the benefits on its response time because most of the calls reuse the cached value.
From the user perspective, this pattern improves the global response time.
-
Microservice bindings (HTTP / REST)
-
Caching
-
Time To Live (TTL)
-
Response time & Responsiveness
This mission has:
-
A user page demonstrating the mission – this page is served by the first microservice (Greeting Service)
-
The Greeting Service responding greetings upon requests. This service relies on the Cute Name Service
-
The Cute Name Service computing a cute name. This call takes at least 2 seconds (this time must be handled in the implementation).
-
The Cache Service used by the Greeting Service to store the last response from the Cute Name Service.
Note: The step 1 to 3 should be automated by the booster deployment. The user or launcher deploys the JDG Cache Service. Instructions are available on here
oc create -f templates/caching-service.json
oc new-app --template=caching-service \
--param=NAMESPACE=jdg \
--param=APPLICATION_NAME=jdg-caching-service \
--param=IMAGE=registry.access.redhat.com/jboss-dataservices/datagrid-online-services\
--param=APPLICATION_USER=jdg-user-
The user deploys the Cute Name Service. A service is exposed.
-
The user deploys the Greeting Service. A route is exposed.
-
User Flow starts - The user accesses the page exposed by the Greeting Service. The page should indicate whether the cached value (the last retrieved cute name) is cached and still valid.
-
User can see on the page: A button to invoke the Greeting Service, a field/box showing the current status of the cache, which initially is clear. Each field/box has a tooltip showing more information.
-
The user clicks on a button invoking the Greeting Service relying on the Cute Name Service. The response time is measured in the web page. As it’s the first call, there is no cached value. The Greeting Service needs to check whether a value has been cached, and if not call the Cute Name service. The response is stored in the cache with a TTL (5 seconds by default).
-
The user clicks another time on the button. The Greeting Service retrieved the cached value and can answer to the request immediately.
-
All requests emitted within the set TTL window benefits from the cached value. Once this period is over, back to step 5.
-
The user can also click on the clear cache button to invalidate the data stored in the cache. The next access to the Greeting Service is slow as the Cute Name Service needs to be called.
This workflow provides a way to measure the benefits from the cache.
The Greeting Service must use the cache in the most idiomatic way depending on the runtime. The different runtimes such as Eclipse Vert.x, Wildfly Swarm, Node.js and Spring Boot have different approaches dealing with caches. It’s up to the runtime team to provide natural integration. However, the rest of the mission stays unchanged.
Each runtime decides which Hot-Rod client to use. Runtimes can also decide how they locate the JDG server. Service discovery (using the kubernetes API or DNS) is recommended.
We make the hypothesis that the full system is deployed (JDG, Greeting and Cute Name services).
| Steps | Action | Assertions | Notes |
|---|---|---|---|
1 |
Deployment of Infinispan, and the services. Wait for readiness |
All pods ready |
|
2 |
Invocation of the Greeting Service ( |
HTTP |
Measure the response time (in the UI). Store the |
3 |
Invocation of the Greeting Service( |
HTTP |
As the cute name should be retrieved from the cache, the response time must be lower than the one measured in step 2. |
4 |
Wait for TTL (5 seconds) |
Alternatively, we can poll |
|
5 |
Invocation of the Greeting Service( |
HTTP |
|
6 |
Clear the cache and retest |
Offer a button to clear the cache completely. Once done, the service will again become “slow” for the first time. This action clears the cache completely |
The Greeting Service is very close to the one developed in the booster 100 - HTTP API. The main endpoint is /api/greeting returning a JSON object containing the message attribute with the value hello %cutename. The main difference with the 100 - HTTP API booster is that we don’t use the name passed by the user, but we retrieve the cute name from the cute name service or from the cache if the cache contains a value. The key used in the cache should be “cute-name”.
In addition to /api/greeting, the greeting service must provide a few other endpoint as described in the following table:
| Method | Path | Expected result | Notes |
|---|---|---|---|
GET |
|
Status Code: |
The endpoint must check if the cache contains a value. If the cache contains a value, this value is used. If not, the value is retrieved from the Cute Name service and cached. |
GET |
|
Status Code: |
This endpoint checks whether or not a value is cached (and still valid) This endpoint does not returned the cached value. |
DELETE |
|
Status Code: |
This endpoint clears the cached value if any. In any case it returns a |
The cute service needs to delay the response time by 2 seconds. Basically, the cute name service computes a random name by concatenating one adjective and one noun. It should take care to not regenerate the same name twice (for a given deployment).
An example of implementation is available here.
The cute name service exposes a HTTP endpoint behaving as follows:
| Method | Path | Expected result | Notes |
|---|---|---|---|
GET |
|
Status Code: |
The endpoint delays the response by 2 seconds and then generate a name a described above. |
The application manipulates the cache using an explicit asynchronous API. This Cache client needs to be developed outside of the scope of this mission.
The application is expected to rely on the @Cacheable annotation. See caching guide for details.
-
Extend or build a new mission to allow caching of database accesses. Particular implementations will use Hibernate ORM second level cache.
-
Extend the mission to accept the service catalog binding approach.
-
Use generated secrets to handle authentication
Product Management |
☐ |
|
DevExp |
☐ |
|
Vert.x |
☑ |
|
WildFly Swarm |
☑ |
|
Spring Boot |
☐ |
|
QE |
☑ |
|
Docs |
☑ |
|
Architect |
☐ |