HATEOAS Link and Method performance

Question

We are using HATEOAS to great effect however we have been looking at performance and getting very poor results from the building of the links, namely code which looks like this

resource.add(linkTo(methodOn(SomeController.class).findAll())).withSelfRel());

Results (I am not as concerned about the size but recorded below anyway)

Enabled links - ~438ms - 201 kb
Disable links - ~193ms - 84.6 kb

The size is due to us putting out 8 links per resource so we expected the size, but not the speed slow down.

Approximately 232ms is spent on constructing links roughly 2ms per object I return (100 objects in this particular test)

Is there anyway to speed this up? Can we get the URI upfront for all request in the toResources call for example and then flavor it in the toResource?

Dost

switching to not using methodOn and instead providing a Controller.class, Method, Params cuts the cost down to ~306ms – Dost

What exactly are you measuring? – Iseabal

I think it is clear up above isn't it? The amount of time to create a link to a controller method? – Dost

Don't ask me, you should know. Measuring only the link creation time would result in 0ms for "Disable links". And yes, since you implement the ResourceAssembler you decide how to get the URLs, so you can get them upfront or cache them (or part of them). – Iseabal

Indeed, which is what I am now doing, the timings above are just relative to each other. So it shows that it takes ~232ms to initialise links by going via the controllers using the examples that the documentation provides. I am dropping the use entirely of the HATEOAS support part of constructing links and building and caching them myself instead now as doubling the length it takes for a request just to build a URI is far too long – Dost

Do you use URI templates in the generated links? – Natation

Answer 1

I had a look at the code around linkTo(methodOn()) and it looks like a lot of AOP magic. A proxy is generated is generated every time you call methodOn for the target interface.

My feeling is that this is great for testing when you want to avoid hard-coding URIs. EntityLinks provides an alternative which should be much more efficient. But it is not as powerful as ControllerLinkBuilder.

An alternative is to use a Helper class in combination with EntityLinks. The spring-restbucks projects contains a nice example - the PaymentLinks class.

But to be honest - it is hard to compete with the convenience provided by ControllerLinkBuiler.

EDIT: Please see my answer here for a more elaborate comparison of link builder performance.

Abnormity