谢谢 @merefield，这正是我们尝试过的：slight_smile:
可惜，它仍然会先加载用户列表页面，然后才重定向到地图。
我原本希望 /map 或类似路径能直接显示地图：slight_smile:
2 个赞
明白了。
但这其实是个误导。
原生用户列表是缓存的，因此加载速度极快，几乎瞬间完成。问题在于加载地图模型所需的时间，在您的情况下，是一次性加载约 400 个用户……所以没错，用户列表的渲染只占用了 0.1% 的处理时间，真正的问题在于后者。这可能没有快速的解决方案。
我之所以部分了解这一点，是因为我刚部署到一个之前未使用过此功能的网站。地图数据加载得非常快，以至于用户列表从未显示出来（尽管它先加载）。问题在于？目前只有 2 个用户标记了位置……用户地图以其当前的架构扩展性不佳。
3 个赞
有趣的见解，谢谢。
目前我们只有约 12% 的社区成员在地图上，我们最近正在讨论开展一项活动，以吸引更多成员加入。
我这样理解对吗：随着我们社区持续增长，地图加载速度会变得越来越慢？
2 个赞
我也猜它得先加载用户列表？
我对代码一无所知，能不能把地图单独放在某个地方？
2 个赞
就像我说的，那无关紧要。用户列表已缓存且非常短。
2 个赞
Locations 插件是使用它自己的模型，还是使用现有的核心模型？我想知道，仅仅从数据库中选取 400 行用户信息时，瓶颈究竟在哪里？
抱歉问了这么多问题 @merefield，只是想更深入地了解其内部运作机制 
2 个赞
没问题，Richie。我们重写了 DirectoryItemsController，以便一次性加载更多人员，这比正常表格分页时加载的数据量要大。模型本身没有区别。
这确实需要从头到尾进行替换，采用一个更复杂的数据流系统，该系统能够感知视口的大小和位置。我怀疑这需要大量工作。其中一个原因是，它将无法再利用 Discourse 自带的大量代码，因为这是一个完全不同的使用场景。不过，这确实是一项很有趣的工作！
你每次都会遇到这个延迟，这表明问题并非出在缓存上，这可能是一个我们无需进行大规模改动就能修复的问题。
4 个赞
我没有漏掉或更改什么简单的 Discourse 设置吧？：facepalm:
2 个赞
不，这不是你的问题，除非你已经超出了当前插件的能力范围
等我得空时，我会研究一下如何缓存结果，这样你每会话只会遇到一次该问题。这是最容易实现的改进。
不过，更大的挑战在于……
2 个赞
谢谢 @merefield，但请先暂缓此事。我目前没有确凿证据，但我强烈怀疑人们每会话本来也就只看一次地图
2 个赞
一个错误报告。
这个错误已经存在一段时间了，但我终于发现是位置插件的问题。当我禁用该插件时，我的网站在用户卡片上显示正确；但一旦启用它，网站就会显示两次！以下是悬停时出现的用户卡片截图：
以及完全展开的个人资料页面的另一张截图：
我通过尝试更改个人资料中的各种值组合，多次测试了这个问题。只有在禁用位置插件时，网站才会正确显示一次。
2 个赞
谢谢 Kartik，你使用的是最近的更新吗？
2 个赞
是的，我本该提一下的。
编辑：为重复元素生成的 HTML 如下：
<span id="ember858" class="ember-view"> <div id="ember860" class="user-location-and-website-outlet replace-location ember-view"><!----><div class="user-profile-website">
<svg class="fa d-icon d-icon-globe svg-icon svg-string" xmlns="http://www.w3.org/2000/svg"><use xlink:href="#globe"></use></svg>
<span title="http://ks.cs.uchicago.edu">ks.cs.uchicago.edu</span>
</div>
</div>
</span>
3 个赞
我现在正忙于客户工作，但会在下个月1日至5日的下一个支持升级期临近时留意此事。
2 个赞
有趣的是，其中一个被样式化为可点击的链接，而另一个则没有
同样有趣的是，我们在论坛上并未遇到这个问题。
2 个赞
我们似乎又遇到了一个问题 @merefield
我们的用户地图目前显示有 472 名用户，但一些用户报告称他们的标记在地图上未显示。然而，当查看他们的用户卡片时，他们却在自己的小地图上显示正常。
当我们在数据库中查询已添加位置的用户时，得到了 492 条结果，因此看起来大约有 20 名用户在地图上不可见。
我们能否采取一些措施来帮助调试这个问题？
查看 Chris 的用户卡片，他在自己的地图个人资料中显示正常：
完整/主地图中，Chris 缺失了
1 个赞
这个设置的值是多少，Richie？
对于示例中缺失的用户，能否请您通过私信（PM）告诉我从 Rails 控制台执行以下命令的结果：
myuser = User.find_by(username: "===USERNAME===")
myuser.custom_fields["geo_location"]
2 个赞
情况越来越复杂了 
它原本被设置为 500。
我把它改成了 1000，我们失踪的人员立刻出现了
我会按你的要求通过私信发给你结果 
2 个赞
啊，这样的话，就不需要通过私信发送该信息了。我怀疑带有 geo_locations 的人员列表可能包含了一些该字段为空的情况（例如自定义字段存在但对象为空），因此你可能触发了最大数量限制。提高最大数量限制，即使存在空值，也不会将有效用户挤出列表。当然，那里的代码确实可以优化，但目前并非关键问题。
2 个赞
感谢 @merefield。我们注意到有几位用户的值中包含类似 '{}' 的内容，我猜他们可能曾经有过位置信息，但后来已被移除。
我也记不清在用户被匿名化时，这些值是否会被删除——这同样会让我们触碰到之前设定的 500 这个关键阈值。
谢谢
2 个赞