CODEWITHSUNDEEP
javaperformanceweb-servicesrestspring-boot
Tnadev
Tnadev

Reputation: 10072

Way to improve Rest Webservice performance which call other API

I have a webservice ABC

ABC Operations:
A. Call XYZ web service
B. Store response in db
C. return result

Overall ABC Responce time = 18 sec
XYZ Response Time = 8 sec.
Only ABC Response time = 18-8 = 10 sec

I want to minimize response time of ABC service.

How can this be done?

Few things I though:
1.Send part request and get part response = But its not possible in my case.
2. return response and perform db in asynchronous manner. (Can this be done in reliable manner?)
3. Is there any way to improve the db write operation?

Upvotes: 4

Views: 2078

Answers (2)

glytching
glytching

Reputation: 47865

If it is possible to “”perform db in asynchronous manner’’ i.e. if you can respond to the caller before the DB write completes then you can use the ‘write behind’ pattern to perform the DB writes asynchronously.

The write behind pattern looks like this: queue each data change, let this queue be subject to a configurable duration (aka the “write behind delay”) and a maximum size. When data changes, it is added to the write-behind queue (if it is not already in the queue) and it is written to the underlying store whenever one of the following conditions is met:

  • The write behind delay expires
  • The queue exceeds a configurable size
  • The system enters shutdown mode and you want to ensure that no data is lost

There is plenty of prior art in this space. For example, Spring’s Cache Abstraction allows you to add a caching layer and it supports JSR-107 compliant caches such as Ehcache 3.x which provides a write behind cache writer. Spring’s caching service is an abstraction not an implementation, the idea being that it will look after the caching logic for you while you continue to provide the store and the code to interact with the store.

You should also look at whatever else is happening inside ABC, other than the call to XYZ, if the DB call accounts for all of those extra 10s then ‘write behind’ will save you ~10s but if there are other activities happening in those 10s then you’ll need to address those separately. The key point here is to profile the calls inside ABC so that you can identify exactly where time is spent and then prioritise each phase according to factors such as (a) how long that phase takes; (b) how easily that time can be reduced.

If you move to a ‘write behind’ approach then the elapsed time of the DB is no longer an issue for your caller but it might still be an issue within ABC since long write times could cause the queue of ‘write behind’ instructions to build up. In that case, you would profile the DB call to understand why it is taking so long. Common candidates include: attempting to write large data items (e.g. a large denormalised data item), attempting to write into a table/store which is heavily indexed.

Upvotes: 1

prasanna
prasanna

Reputation: 11

As far as I know you can follow the options based on your requirement:

  1. Think of caching the results from XYZ response and store to database so that you can minimise the call.

  2. There could be possibility of failures in option 2 but still you can fix it by writing the failure cases to error log and process it later.

  3. DB write operation can be improved with proper indexing, normalisation etc..

Upvotes: 1

Related Questions