与Gremlin Shell相比，Gremlin Server REST API中的查询速度较慢
我正在使用tinkerpop3 gremlin服务器。
我执行一个简单的查询（使用标准RESTAPI）来获取顶点的边。
g.traversal().V(123456).outE('label')
当有很多结果（大约2000-3000）时，查询很慢，超过20秒才能得到JSON-结果响应。
有趣的是，当我使用gremlin shell运行同一个查询时，大约需要1秒的时间来接收边缘对象结果！
我不确定，但我怀疑可能gremlin-server的JSON解析器（我正在使用Graphson）有问题（可能非常慢）。
有什么想法吗？谢谢
共有1个答案
这看起来确实很慢，但它正在内存中构建一个潜在的大结果集，并且序列化一个图元素（例如整个Vertex或Edge）有点“重”，因为它试图匹配Vertex/Edge API层次结构的一般结构。我们已经看到了通过将查询更改为：
g.V(123456).outE('label').valueMap()
或者如果您还需要id/标签：
g.V(123456).outE('label').valueMap(true)
通过这种方式，顶点/边的层次结构被展平为一个简单的贴图，具有更少的序列化开销。简而言之，限制客户端实际需要的数据量以提高性能。
-
问题内容： 它们看起来几乎一样，甚至是语法？ 使用什么？或什么时候使用什么？ 问题答案： 速度不再是真正活跃的开发。Freemarker是。 根据我的经验，Freemarker也更加灵活。
-
我是PostgreSQL的新手，我面临着一个关于表函数性能的问题。我需要做的是相当于MSSQL中的存储过程。经过一些研究，我发现一个表函数是可行的，所以我举了一个例子，用plpgsql创建了我的函数。 通过比较执行时间，使用函数比直接调用查询慢2倍（查询在函数中完全相同）。 经过一点挖掘，我发现在函数中使用SQL语言可以大大提高执行时间（与调用查询的时间完全相同）。读了这篇文章后，我了解到plpg
-
我有一个ASP。NET核心系统（基于NopCommerce框架）托管在Azure VM上（标准F8s\U v2大小）。应用程序运行非常平稳。平均响应时间约为200 ms，这是可以接受的。同样的应用程序托管在Azure应用程序服务（P2v2计划）上。速度明显较慢。平均响应时间约为500 ms。 我做了大量的监控分析： Azure应用程序服务和VM上的CPU均较低。单个请求的CPU在应用程序服务上约为
-
JavaScript 有两种方式判断两个值是否相等。 等于操作符 等于操作符由两个等号组成：== JavaScript 是弱类型语言，这就意味着，等于操作符会为了比较两个值而进行强制类型转换。 "" == "0" // false 0 == "" // true 0 == "0"
-
git show git show 命令可以以一种简单的人类可读的方式来显示一个 Git 对象。 你一般使用此命令来显示一个标签或一个提交的信息。 我们在 附注标签 一节中使用此命令来显示带注解标签的信息。 然后，我们在 选择修订版本 一节中，用了很多次来显示不同的版本选择将解析出来的提交。 我们使用 git show 做的最有意思的事情是在 手动文件再合并 一节中用来在合并冲突的多个暂存区域中提
-
现在你有了一堆分支，短期的主题、长期的特性或者其它。怎样追踪他们呢？Git 有一组工具，可以帮助你弄明白工作是在哪儿完成的，两个分支间的区别是啥，等等。 简而言之 执行 git log 找到你的项目历史中的特定提交 ——按作者、日期、内容或者历史记录。执行 git diff 比较历史记录中的两个不同的点 ——通常是为了看看两个分支有啥区别，或者从某个版本到另一个版本，你的软件都有啥变化。 git