firebase - Firebase云功能过慢(Firebase cloud functions unreasonably slow)

Question

We run a Firebase application using onCall heavily.

(我们大量使用onCall运行Firebase应用程序。)

The problem, however, is that the functions answer unreasonably slow.

(但是，问题在于这些函数的响应速度过慢。)

Simple functions take 4 seconds to answer even after repeat invocations.

(即使重复调用，简单的功能也需要4秒钟来回答。)

Som things we already take into account:

(索姆我们已经考虑到的事情：)

• Coldstart: We are aware that Firebase cloud functions can be slow when they have not been run for a while.

  (Coldstart：我们知道，Firebase云功能一段时间未运行可能会变慢。)

  We still have the problem after repeat invocations.

  (重复调用后，我们仍然遇到问题。)

• Large result set: The responses are slow even when Firestore result sets are empty.

  (结果集大：即使Firestore结果集为空，响应也很慢。)

• CORS OPTIONS preflight also take unreasonably long to response (often 4-8 seconds)

  (CORS OPS选项飞行前也需要花费不合理的时间（通常4-8秒）)

• We are on a Blaze plan.

  (我们正在大火计划中。)

• The same call with the same result size yield very different

  (具有相同结果大小的同一调用产生的差异非常大)

In the following picture, none of the calls are other than simple Object retrievals.

(在下图中，所有调用都不是简单的对象检索。)

None of the documents in the result sets trigger further checks.

(结果集中的任何文档都不会触发进一步检查。)

Still we have more than 8 seconds for retrieving 66KB woth of data.

(仍然需要8秒钟以上的时间来检索66KB的全部数据。)

Following image are merely for preflight requests.

(以下图像仅用于飞行前的要求。)

We do not expect those to even hit our code.

(我们不希望那些代码甚至会破坏我们的代码。)

Is that wrongly assumed?

(这是错误的假设吗？)

Lastly, it should be mentioned that we are based in the EU and that the servers are located in the US.

(最后，应该提到的是，我们位于欧盟，而服务器位于美国。)

But we don't think that this explains 4 second response times.

(但是我们认为这不能解释4秒的响应时间。)

  ask by Mads Buch translate from so

Answer 1

I have exactly the same problem with callable functions to retrieve customClaims , after using stack drive to monitor the function for several days I concluded it is caused by cold starts.

(我使用可调用函数检索customClaims完全相同的问题，在使用堆栈驱动器监视函数几天后，我得出结论，这是由冷启动引起的。)

Take a look those in orange, it seems when the same instance is warm it works like charm as you mention on your case, as soon as, it gets cold (after around 15 mins), we find the peeks again.

(看看橙色的那些，似乎当同一实例变热时，就像您在案子中提到的那样，就像魅力一样，一旦变冷（大约15分钟后），我们便再次发现了偷看者。)

This also brings other challenges... take a look at this.

(这也带来了其他挑战……看看吧。)

The fact that we are using an instance at the same time, it doesn't mean everyone will use that instance (during that time), I've found when several users call the function during the same time and it's cold, it spins up more instances (up to 6 on the same).

(我们同时使用一个实例这一事实，并不意味着每个人都将使用该实例（在这段时间内），我发现当多个用户在同一时间调用该函数并且很冷时，它就会旋转更多实例（同一实例最多6个）。)

I haven't nailed the right formula to decrease those times while keeping a decent amount of security around but I've documented a few findings , maybe they might help (they are on background functions only) I will make the same tests on callable functions soon,

(我没有确定正确的公式来减少这些时间，同时又保持了相当可观的安全性，但是我记录了一些发现 ，也许它们可能会有所帮助（它们仅在后台函数中），我将对可调用函数进行相同的测试不久，)