HATEOAS 链接和方法性能答案

【问题标题】：HATEOAS Link and Method performanceHATEOAS 链接和方法性能
【发布时间】：2014-11-21 10:05:31
【问题描述】：

我们使用 HATEOAS 取得了很好的效果，但是我们一直在关注性能并从构建链接中得到非常糟糕的结果，即看起来像这样的代码

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

结果（我不关心大小，但无论如何都记录在下面）

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

大小是由于我们为每个资源提供了 8 个链接，因此我们预期大小，但速度不会减慢。

大约 232 毫秒用于构建链接，每个我返回的对象大约 2 毫秒（在此特定测试中为 100 个对象）

有没有办法加快速度？例如，我们能否在 toResources 调用中为所有请求预先获取 URI，然后在 toResource 中对其进行调整？

【问题讨论】：

切换到不使用 methodOn 而是提供 Controller.class、Method、Params 将成本降低到 ~306ms
你到底在测量什么？
我想上面说的很清楚了吧？创建到控制器方法的链接需要多长时间？
别问我，你应该知道的。仅测量链接创建时间将导致“禁用链接”为 0 毫秒。是的，因为 you 实现了 ResourceAssembleryou 决定如何获取 URL，因此您可以预先获取它们或缓存它们（或其中的一部分）。跨度>
确实，这就是我现在正在做的，上面的时间只是相对的。因此，它表明使用文档提供的示例通过控制器初始化链接需要大约 232 毫秒。我现在完全放弃使用 HATEOAS 支持部分来构建链接并自己构建和缓存它们，因为仅构建 URI 的请求所需的长度加倍太长了

【解决方案1】：

我查看了linkTo(methodOn()) 周围的代码，它看起来像很多 AOP 魔法。每次为目标接口调用 methodOn 时都会生成一个代理。

我的感觉是，当您想避免硬编码 URI 时，这非常适合进行测试。 EntityLinks 提供了一种更有效的替代方案。但它没有ControllerLinkBuilder那么强大。

另一种方法是将 Helper 类与 EntityLinks 结合使用。 spring-restbucks 项目包含一个很好的例子 - PaymentLinks class。

但说实话 - 很难与 ControllerLinkBuiler 提供的便利性竞争。

编辑：请参阅我的回答here，以更详细地比较链接构建器的性能。

【讨论】：