使用Cloudflare工作人员消除冷启动

“冷启动”是第一次加载和执行无服务器函数的新副本所需的时间。这是一个既复杂又昂贵的问题。其他无服务器平台会让您选择是忍受执行时间的随机增加，还是通过合成请求来保持函数温暖。冷启动是一种可怕的体验，特别是当无服务器容器可能需要整整几秒钟才能预热的时候。

与容器不同，Cloudflare Workers使用隔离技术，该技术可在个位数毫秒内测量冷启动。嗯，至少他们是这么做的。今天，我们正在完全消除对冷启动的担忧，通过引入对完全没有冷启动的工人的支持-没错，零。忘了冷启动，热启动，或者...。任何开始，使用Cloudflare Workers，您都可以在全球200多个城市获得始终火爆的原始性能。

让每个人的函数一直在内存中保持温暖是不切实际的。相反，无服务器提供程序仅在收到第一个请求后才预热函数。然后，在一段时间的不活动之后，功能再次变冷，循环继续。

对于工人来说，这从来不是什么大问题。与可能花费整整几秒钟为每个功能启动新的集装箱化进程的容器不同，Workers背后的隔离技术允许它在不到5毫秒的时间内预热一个功能。

冷启动很难看。它们是意想不到的、不可避免的，并且会导致不可预测的代码执行时间。您不应该为了享受无服务器的好处而损害客户的体验。在我们的员工团队和网络团队的共同努力下，我们着手创建一个解决方案，让您再也不用担心冷启动、热启动或预热。

与Cloudflare的许多功能一样，安全和加密使我们的网络更加智能。由于95%的工作人员请求都是通过HTTPS安全处理的，因此我们设计了一个使用互联网加密协议的解决方案，这对我们很有利。

在客户端可以发送HTTPS请求之前，它需要与服务器建立安全通道。此过程在TLS或传输层安全协议中称为“握手”。大多数客户端还在该握手中发送主机名(例如cloudflare.com)，这称为SNI或服务器名称指示。服务器接收握手，发回证书，现在允许客户端发送加密的原始请求。

以前，Worker只有在整个握手过程完成后才会加载和编译，这涉及客户端和服务器之间的两次往返。但是等等，我们想，如果握手中有主机名，为什么要等到整个过程完成后才预加载工作进程呢？由于握手需要一些时间，因此在请求到达之前的等待时间内有机会预热资源。

在我们的最新优化中，当Cloudflare在TLS协商期间收到第一个数据包“ClientHello”时，我们会提示Worker运行时急于加载该主机名的Worker。握手完成后，工作人员就暖和起来，可以接收请求了。由于加载工作进程只需要5毫秒，而客户端和Cloudflare之间的平均延迟超过5毫秒，因此冷启动为零。一旦从客户端接收到请求，工作器就开始执行代码。

现在，为了每个人！我们已经向所有工人客户推出了这一优化，并于今天投入生产。不需要额外费用，也不需要更改配置。当您在Cloudflare Workers上构建时，您就构建在一个智能的分布式网络之上，该网络不断突破性能方面的极限。

目前，这仅适用于部署到“example.com”等“根”主机名的Worker，而不适用于“example.com/path/to/thing”等特定路径。我们计划在未来引入更多可以预加载特定路径的优化。

我们也认识到，业绩不仅仅是零个冷开始。这就是为什么我们在本周早些时候宣布了“工人解放”测试版的原因。Worker Unbound拥有Worker的简单性和性能，没有限制，只有原始性能。

配备零冷启动、无CPU限制且网络覆盖200多个城市的员工处于最佳状态，随时可以承担任何严重的工作负载。这就是表演。

无服务器周无服务器Cloudflare工作人员JavaScript产品新闻