将AQL查询从ArangoDB原生REST API移至Foxx微服务后性能下降是否正常？

首先，原生的/api/cursor端点是ArangoDB核心层面实现的，经过了高度优化，几乎没有额外的请求处理开销；而Foxx微服务作为运行在ArangoDB之上的应用层，确实会引入一些额外的处理步骤——但正常情况下，这种开销不应该导致性能出现显著下降，大概率是你的实现方式有可以优化的空间。

常见的性能瓶颈点和解决办法 #

• 查询语句的选择错误
  你当前用的return LENGTH(MyCollection)会让ArangoDB遍历集合里的所有文档来计数，这本身就不是最高效的方式。换成直接调用集合的count()方法会快得多，因为它直接读取ArangoDB维护的集合统计数据，不需要遍历文档：

  // 替换原来的db._query('LENGTH(MyCollection)')
  db._collection('MyCollection').count()
  

  这个改动本身就能大幅提升查询性能，不管是在原生API还是Foxx里。

• Foxx服务的代码冗余
  很多人会在Foxx的请求处理函数里重复做一些初始化操作，比如每次请求都重新获取集合实例，这会增加不必要的开销。建议把集合实例缓存到模块级别，而不是每次请求都创建：

  // 在Foxx服务的主文件顶部（模块级别）缓存集合
  const myCollection = module.context.collection('MyCollection');
  
  // 请求处理函数里直接使用缓存的实例
  router.get('/get-count', function(req, res) {
    res.send({ count: myCollection.count() });
  });
  

• 不必要的中间件或逻辑
  如果你的Foxx服务添加了额外的中间件（比如全局日志、自定义认证、参数校验等），这些都会增加每个请求的处理时间。检查一下这些中间件是否是必须的，或者有没有优化的空间——比如把日志改成异步输出，或者简化认证逻辑。

• Foxx的上下文开销
  每个Foxx请求都会初始化一个请求上下文，如果你的服务里有大量的自定义逻辑依赖这个上下文，也会增加耗时。可以尽量把通用逻辑移到模块级别，避免在请求周期内重复执行。

验证优化效果 #

你可以用ArangoDB Web UI里的Metrics面板，对比原生API和Foxx服务的请求耗时，看看瓶颈是在数据库查询阶段，还是Foxx的处理阶段。如果优化后Foxx的性能还是和原生API差距很大，可以考虑：

1. 检查ArangoDB的版本，有些旧版本的Foxx存在性能问题，升级到最新稳定版可能会解决。
2. 尝试把Foxx服务的路由简化到最基础的程度，去掉所有非必要的逻辑，再测试性能。

总的来说，通过合理优化，Foxx服务的性能应该能接近原生API的水平，不会出现显著的下降。

内容的提问来源于stack exchange，提问作者Nunzio Ewald