我已经使用 Union Platform 实现了 JOOQ 作为基于 java 的游戏服务器，并使用 Union Platform 的 Orbiter Micro（Union JS 客户端）在浏览器上运行它。
然而，对于30-40名活跃玩家的小规模赛事，联盟平台在速度上有所落后。
对于每个游戏实例（即每个房间），我配置了一个执行所有查询的工厂连接。它的作用是，
对于每个玩家的回合，
- 玩家可以输入一个整数，经过一系列（4 个查询）条件检查后，它通过 JOOQ 插入/更新数据库
- ，然后为了取回整数的状态，它再次执行 3 个查询它有效地转化为 3 个链接哈希图来更新游戏状态。
现在，响应需要花费很长时间，玩家会发现性能问题。而联盟平台实际上声称可以轻松处理同时超过 1000 名活跃玩家。因此，这实际上意味着我的 JOOQ 查询中存在一些错误（我确实使用了很多 LEFT OUTER JOIN）。
因此，任何有关提高吞吐量和分析每个查询的建议都是非常受欢迎的。
I already have implemented JOOQ with Union Platform as a java based game server and using Union Platform's Orbiter Micro (Union JS Client) for running it on a browser.
However, event with small 30-40 active players in the game, the Union Platform is lagging in terms of speed.
For each game instance (i.e each room) , i have configured one factory connection which executes all the queries. What it does is ,
For each player's turn,
- player can put in an integer and after a series (4 queries) of condition checks, it inserts/updates the db via JOOQ
- and then to get back the integer's status, it again executes 3 queries which effectively translates into 3 linked-hashmaps for updating the status of the game.
Now, the response is taking so much time, that players are seeing performance issues. While Union Platform actually claims to handle more than 1000 active players at an instance easily. So this effectively means that there is some mistakes in my JOOQ queries (I did used a lot of LEFT OUTER JOINs).
So any suggestion to improve the throughput and to profile each query is very much welcome.
发布评论
评论（1）
对我来说，这听起来像是正常的 SQL 调优问题（或者可能是几个不同的问题）。鉴于 jOOQ 允许您执行实际的 SQL，并且在没有正确的索引和约束的情况下使用 OUTER JOIN 时可能会出现很多错误，因此问题很可能出在 SQL 本身上。当你打开调试/跟踪日志记录时，jOOQ 会打印出几条信息到日志输出，包括
DEBUG 级别的
TRACE 级别
如果您输入 log4j 或 slf4j 与 jOOQ 一起位于您的类路径中。更多详细信息请参阅此博客文章
这是一个开始。您还可以使用 Yourkit Profiler 或 JProfiler。显然，您应该考虑您的 Postgres 执行计划。 Postgres 文档 中有一些相关说明。
That sounds like normal SQL tuning question (or maybe several distinct ones) to me. Given that jOOQ lets you execute actual SQL, and there is a lot that can go wrong when using
OUTER JOINwithout correct indexing and constraints, it is likely that the problem is with the SQL itself. When you turn on debug / trace logging, jOOQ will print out several pieces of information to the log output, includingDEBUG level
TRACE level
This will work if you put log4j or slf4j on your classpath along with jOOQ. More details are documented in this blog post
That's a start. You could also use a tool like Yourkit Profiler or JProfiler. And obviously, you should consider your Postgres execution plans. There are some indications about that here in the Postgres documentation.