在 Grails 中从服务返回到控制器时间答案

【问题标题】：Return from Service to Controller time in Grails在 Grails 中从服务返回到控制器时间
【发布时间】：2012-02-01 14:30:50
【问题描述】：

我们正在研究 grails 应用程序的性能，似乎 grails 需要很多时间（7-13 毫秒）才能从服务中恢复到控制器。返回的数据是对域对象的引用（带有 2 个引用的映射），不是很复杂。有什么办法可以缩短这个时间？

我们在服务中的 return 语句之前有 log.debug()，在离开服务之后，在控制器中还有一个。

2012-02-01 15:16:07,048 [http-8080-1] DEBUG api.TestService test before service return
2012-02-01 15:16:07,063 [http-8080-1] DEBUG api.TestController test after service return

编辑：Grails 1.3.7 版

编辑：开启休眠 SQL 日志记录后：

2012-02-02 09:20:04,504 [http-localhost%2F127.0.0.1-8080-1] DEBUG api.TestService before return
2012-02-02 09:20:04,505 [http-localhost%2F127.0.0.1-8080-1] DEBUG hibernate.SQL select nextval ('hibernate_sequence')
2012-02-02 09:20:04,516 [http-localhost%2F127.0.0.1-8080-1] DEBUG hibernate.SQL insert into test ...
2012-02-02 09:20:04,520 [http-localhost%2F127.0.0.1-8080-1] DEBUG hibernate.SQL update test1 ...
2012-02-02 09:20:04,522 [http-localhost%2F127.0.0.1-8080-1] DEBUG hibernate.SQL insert into test_test1 ...
2012-02-02 09:20:04,524 [http-localhost%2F127.0.0.1-8080-1] DEBUG api.TestController after service

【问题讨论】：

您是否尝试过使用调试器单步执行代码，深入 grails 的内部，看看它的去向？
你能提供一些信息吗？你在服务中做什么？地图有多少元素？代码 sn-ps?
认真的吗？您担心 7 到 13 毫秒？
哇！需要 60 毫秒的 api 中的 7 到 13 毫秒是时间的 1/5！ 100 个请求浪费了 10 毫秒等于浪费了一秒 :)
主题：地图的内容重要吗？它应该是引用传递而不是对象本身。

标签： performance spring grails spring-mvc

【解决方案1】：

开销可能是由 Spring 围绕服务调用构建事务上下文引起的（Grails 默认，参见http://grails.org/doc/2.0.x/guide/services.html#declarativeTransactions）。如果您的服务不需要（数据库）事务，请确保添加

static transactional = false

在服务中。

如果您确实需要事务并且您正在从控制器执行大量服务调用，则值得将它们转移到服务中，这样您就可以处理最少数量的事务。（如果您绝对希望将它们保留在控制器中，可以使用 withTransaction 块在单个事务中执行多个服务调用。）

【讨论】：

Youre right. After adding some more logging weve 注意到，事务在离开 Service 时结束，插入和更新持续这么久。打开休眠 SQL 调试后，我用日志编辑了问题。

【解决方案2】：

7 到 13 毫秒几乎是瞬时的。您正在浪费时间试图进一步减少这种情况。你肯定还有其他更重要的事情要做吗？

即使这是您最紧迫的问题，花时间在上面似乎也没什么意义，因为您实际上无能为力，因为它是 Grails/Spring 代码（而不是您的），而不是在服务和控制器之间执行.

【讨论】：

所以你是说从一种方法返回到另一种方法需要 7 到 13 毫秒是可以的吗？不是 API 调用需要 7-13 毫秒，而是从服务到控制器。因此，为了满足 SLA，这是需要研究的事情之一。
是的。如果您关心毫秒级的性能，您应该使用经过微调的汇编语言来编写您的应用程序。
伯特，我不同意。我认为你是从一个极端[不关心性能]走向另一个[性能为王]。我们要做的是写在像 Grails 一样灵活的东西，并尽可能多地从中挤出。这样做时，我们正在寻找易于微调的瓶颈[例如将长循环移动到 java]。我们发现，在从服务到控制器的简单返回中，我们损失了超过 1/4 倍的一些 api。由于找不到原因，我们决定询问。请告诉我，这是怎么回事？如果它是一个供 10 个用户使用的 web 应用程序，但事实并非如此。