Spring HATEOAS ControllerLinkBuilder methodOn increasing response times significantly

Question

The setup: So I have a RESTfull API written in java, using spring-boot and spring-hates for adding links to the resource (Hypermedia-D

Answer 1

EDIT:

Updated post to use improved versions - Spring HATEOAS 0.22 and Spring Framework 4.3.5 / 5.0 M4.

Answer:

This is very interesting. I had a look at the source code for the ControllerLinkBuilder methods linkToand methodOn and there is a lot going on for a simple link:

• builds an aop propxy for the controller that records the interactions and gets hold of the method and the parameters to build the link for
• it discovers the mappings of this method to construct the link

The ControllerLinkBuilder is very convenient because it avoids duplicating logic that is already contained in your mapping.

I came up with a simple sample application and a very basic benchmark to measure and compare link builder performance

It is based on a simple controller - it is just returning 100 simple objects - each is carrying one self-link.

@RestController
@RequestMapping("items")
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class TestController {

    private final ItemResourceProcessor resourceProcessor;

    @RequestMapping(method = GET)
    public ResponseEntity>> getAll() {
        List> items = new ArrayList<>(100);
        for (int i = 0; i < 100; i++) {
            items.add(resourceProcessor.process(
                    new Resource<>(new Item(i, UUID.randomUUID().toString()))));
        }

        return ResponseEntity.ok(items);
    }

    @RequestMapping(method = GET, path = "/{id}")
    public ResponseEntity> getOne(@PathVariable Integer id) {
        return null;
    }
}

The ItemResourceProcessor adds a simple self-link and I tried and measured three different alternatives:

1. ControllerLinkBuilder with linkTo(methodOn)

Here ControllerLinkBuilder is used to inspect the mapping on controller and method - which needs an aop proxy for every link generated.

@Component
public class ItemResourceProcessor implements ResourceProcessor> {

    @Override
    public Resource process(Resource resource) {
        resource.add(linkTo(methodOn(TestController.class).getOne(resource.getContent().getId())).withSelfRel());
        return resource;
    }
}

The results for this variant are these:

    wrk -t2 -c5 -d30s http://localhost:8080/items

    Running 30s test @ http://localhost:8080/items
  2 threads and 5 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.77ms    0.93ms  25.57ms   83.97%
    Req/Sec   420.87     48.63   500.00     71.33%
  25180 requests in 30.06s, 305.70MB read
Requests/sec:    837.63

2. ControllerLinkBuilder without methodOn()

Here the call the to methodOn() is avoided and the method reference is determined once at the creation of the resource processor and reused to generate the link. This version avoids the overhead of methodOn but still discovers the mapping on the method to generate the link.

@Component
public class ItemResourceProcessor implements ResourceProcessor> {

    private Method method = ReflectionUtils.findMethod(TestController.class, "getOne", Integer.class);

    @Override
    public Resource process(Resource resource) {
    resource.add(linkTo(method, resource.getContent().getId()).withSelfRel());
    return resource;
    }
}

The results are slightly better than for the first version. The optimization is giving us only small benefits.

wrk -t2 -c5 -d30s http://localhost:8080/items

Running 30s test @ http://localhost:8080/items
  2 threads and 5 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.02ms  477.64us  13.80ms   84.01%
    Req/Sec   499.42     18.24   540.00     65.50%
  29871 requests in 30.05s, 365.50MB read
Requests/sec:    994.03

3. Link generation using BasicLinkBuilder

Here we move away from ControllerLinkBuilder and use BasicLinkBuilder. This implementation is not performing any introspections of controller mappings and is thus a good candidate for reference benchmark.

@Component
public class ItemResourceProcessor implements ResourceProcessor> {

    private ControllerLinkBuilder baseLink;

    @Override
    public Resource process(Resource resource) {
      resource.add(BasicLinkBuilder.linkToCurrentMapping()
            .slash("items")
            .slash(resource.getContent().getId()).withSelfRel());
      return resource;
    }
}

The results are again better than the previous

wrk -t2 -c5 -d30s http://localhost:8080/items

Running 30s test @ http://localhost:8080/items
  2 threads and 5 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.05ms  683.71us  12.84ms   72.12%
    Req/Sec   658.31     87.79   828.00     66.67%
  39349 requests in 30.03s, 458.91MB read
Requests/sec:   1310.14

Summary

Of course, there is an overhead of methodOn(). The tests show that 100 links cost us less than 2ms on average compared to BasicLinkBuilder.

So when the amounts of rendered links are not massive the convenience of ControllerLinkBuilder is making it a good choice for link generation.

DISCLAIMER: I know my wrk tests are not proper benchmarks - but the results could be repeated and showed the same results comparing the alternatives - so they at least can provide a hint on the dimensions of differences in performance)