前端学Serverless系列--性能调优

    1）资源申请：代码比较大，代码解压+load代码 约2.5s+（解压2.4s），如果加上下载估计会在3s多。
如果调用很频繁，正常情况会有2、3百个请求（资源池容器数量）资源申请时间在2.5-3s之间； 如果调用不频繁，耗时2.5s-3s的请求数会更多一些。

2）函数调用：代码本身执行时间：70ms~115ms左右，路径耗时从5ms~600ms不等</code></pre></div></div><p>2、热启动：也就是代码本身执行的时间，这个看代码本身要做的逻辑。机器不是瓶颈，主要是逻辑和需要调用第三方应用的耗时。我这个压测例子的耗时就会在50ms之内，20ms左右。</p><p>3、现在有一些大于5s的，那些耗时都在路径上或者有可能在单节点处理能力上。具体消耗在哪里暂时看不出来。</p><h4 id="bnn9m" name="%E4%BC%98%E5%8C%96%E6%96%B9%E6%A1%88">优化方案</h4><p>1、设置实例保留，减少冷启动。这个最有效，降幅最大，相当于是保留了一个进程随时响应请求。</p><p>2、设置合适的资源池数量，可以大大降低冷启动的耗时。</p><p>3、减少代码量，我这个例子代码量从58M降低了26M，主要是将并不常用而且代码量比较大的库拆分成一个单独的云函数服务。</p><p>理论上结果应该会好看很多了？</p><p>实际上耗时最大的请求的确有所改善，但是平均值和90%的值还是被一些高耗时拉高。</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815679878399319.png" /></div></div></div></figure><p>但是实际上压测大师测的结果依然没有达到很理想，下面汇总一下截止目前阶段的结果。</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815680514590192.png" /></div></div></div></figure><h4 id="dp6aq" name="%E7%BB%A7%E7%BB%AD%E5%88%86%E6%9E%90%E9%97%AE%E9%A2%98%EF%BC%9A">继续分析问题：</h4><p>理论上云函数服务该做的优化都做了，而且理论表现不会这么差才对？</p><p>后来云的同事用python写了脚本来自己压测，发现200并发的平均耗时在200ms之内，而且超过200ms的请求也在可数之内。</p><p>由于两个测试的结果不一致，从自己写的脚本和wetest压测方案两方展开分析。</p><p>1）脚本尽量去还原wetest的方案，如异地部署，阶梯增加并发，并且每个阶段维持30s。</p><p>2）直接找到了wetest的后台同事进行问题沟通，尝试了长连接，短连接，多IP压力源，去掉日志打印等操作。</p><p>结果：这个压测结果其实已经达到了我们预设的优化目标，平均在200ms之内。</p><p>以下还是wetest的压测结果（短连接+多IP）。</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815680986719257.png" /></div></div></div></figure><p>其中还有一个很有意思的结果，长连接下的压测结果：</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815681285729606.png" /></div></div></div></figure><p><strong>那么到底是什么原因导致了这个结果的差异呢？</strong></p><p>“网络连接耗时”</p><p>在这个例子中，将长连接改成短连接，从一地压测改成多IP压测，效果最为明显，去掉日志打印也一定程度减少了压测源的性能损耗。</p><h3 id="a3vv9" name="%E7%94%A8%E6%88%B7%E4%BE%A7%E5%AF%B9%E6%AF%94%E8%AF%84%E6%B5%8B">用户侧对比评测</h3><p>既然地域不同，网络不同，耗时差异这么大，那么真实的用户耗时到底如何呢？</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815681937674919.png" /></div></div></div></figure><p>红色的是Serverless，黄色的是原来的NodeServer。</p><h4 id="c1s7j" name="%E5%88%86%E6%9E%90%E9%97%AE%E9%A2%98">分析问题</h4><h5 id="393al" name="1%E3%80%815%E6%9C%885%E6%97%A5%E9%92%88%E5%AF%B9Serverless%E5%81%9A%E4%BA%86%E4%BC%98%E5%8C%96%EF%BC%9A%E5%B0%86%E9%9D%9E%E7%AE%80%E5%8D%95%E8%AF%B7%E6%B1%82%E6%94%B9%E6%88%90%E7%AE%80%E5%8D%95%E8%AF%B7%E6%B1%82%EF%BC%8C%E5%87%8F%E5%B0%91%E4%B8%80%E6%AC%A1%E2%80%9C%E9%A2%84%E6%A3%80%E2%80%9D%E8%AF%B7%E6%B1%82%EF%BC%8C%E5%8A%A0%E4%B8%8Adns-prefetch%EF%BC%9B%E5%8A%A0%E4%B8%8A%E4%BA%86NodeServer%E5%8E%9F%E6%9D%A5%E7%9A%84%E8%AF%B7%E6%B1%82%E8%80%97%E6%97%B6%E8%BF%9B%E8%A1%8C%E5%AF%B9%E6%AF%94%E3%80%82">1、5月5日针对Serverless做了优化：将非简单请求改成简单请求，减少一次“预检”请求，加上dns-prefetch；加上了NodeServer原来的请求耗时进行对比。</h5><p>刚开始是因为设置了header头，浏览器认为这个是非简单请求。</p><p>非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为&#34;预检&#34;请求（preflight）。浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。更详细可以查阅：跨域资源共享 CORS 详解</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815682469910382.png" /></div></div></div></figure><p>图为一个请求产生了两个请求，第一个是预检请求，其中method为OPTION， 返回状态码是204。</p><p>如果要用到非简单请求的时候，服务端响应CORS的设置要注意到：</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815683044130131.png" /></div></div></div></figure><p>如果单选具体的GET，POST，可以在API网关中的API管理中设置是否支持CORS，如果需要支持多个的请求方法的话，就只能后端业务处理。</p><h5 id="7paak" name="2%E3%80%81%E4%BC%98%E5%8C%96%E4%B9%8B%E5%90%8E%EF%BC%8C%E5%8F%91%E7%8E%B0Serverless%E7%9A%84%E8%AF%B7%E6%B1%82%E4%BE%9D%E7%84%B6%E6%AF%94NodeServer%E6%85%A2100ms%E5%B7%A6%E5%8F%B3%E3%80%82">2、优化之后，发现Serverless的请求依然比NodeServer慢100ms左右。</h5><p>继续分析发现：Serverless的请求会比NodeServer请求多一个Initial connection和SSL的时间。</p><p>为什么NodeServer没有呢，因为我们测试的页面和发请求的页面是同域的，所以这部分时间省了。为什么之前Serverless没有发现呢，因为socket连接之后没有那么快销毁，在页面重复刷新的时候，反而是看不到这个耗时的。</p><p>需要清理一下socket： chrome://net-internals/#sockets</p><p>就可以复现了，那么这个耗时差距的原因就很明显了。</p><p>我做了一个简单页面进行测试，发现这样的结果。Serverless和NodeServer的全程耗时其实差不太多，但是TCP连接和SSL时间会长很多。</p><p>这是为什么呢？我测试的这个Serverless是部署在上海的，而我在深圳进行测试的。</p><p>我再做了一个测试，加了一个部署在广州的云函数。</p><p>结果也很明显了。</p><p>异地访问部署的问题，因为原有的NodeServer接入了STGW。</p><p>STGW全称Secure Tencent Gateway，腾讯安全云网关，是一套实现多网统一接入，支持自动负载均衡的系统。由于STGW提供了就近接入和SSL加速，所以这两部分时间都相应有不少的优化。</p><p>那么Serverless能不能用多地部署，就近接入来解决这个问题呢。</p><p>目前Serverless的云函数和API网关都是地域隔离的。也就是说广州的API网关对应广州的云函数，不能一个网关对多个地域的云函数。这个需求和腾讯云的产品沟通之后，纳入到以后的规划建设当中。</p><p>那么我们目前有没有折中的方案呢？</p><p>我们设想了一些中转的方案：</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815683368194832.png" /></div></div></div></figure><p>最后我们选择了最右侧的方案，主要是简单。</p><p>而且还可以继续通过在header中设置preconnect减少TCP握手和SSL的时间。</p><p><code>&lt;link rel=&#34;preconnect&#34; href=&#34;//example.com&#34;&gt;</code></p><p>preconnect的兼容性情况：</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815683967691197.png" /></div></div></div></figure><p>使用之前：</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815684543106944.png" /></div></div></div></figure><p>使用了之后的效果：</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815685076541413.png" /></div></div></div></figure><p>可以看到Initial connection 和 SSL的时间是可以直接节省掉了，在网络差的情况下，这部分节省的时间更为显著。</p><h3 id="3lou1" name="%E5%B0%8F%E7%BB%93%E4%B8%80%E4%B8%8B">小结一下</h3><p><strong>Serverless云函数性能评测和优化结果：</strong></p><p>经过优化之后，Serverless云函数的响应性能已经达到了需要即时返回场景的可用状态。</p><p>在API网关监控到到耗时（不包括网络时间和握手时间）</p><figure class=""><div class="rno-markdown-img-url" style="text-align:center"><div class="rno-markdown-img-url-inner" style="width:100%"><div style="width:100%"><img src="https://cdn.static.attains.cn/app/developer-bbs/upload/1722815685758222643.png" /></div></div></div></figure><p>1、压测方案、问题分析</p><div class="rno-markdown-code"><div class="rno-markdown-code-toolbar"><div class="rno-markdown-code-toolbar-info"><div class="rno-markdown-code-toolbar-item is-type"><span class="is-m-hidden">代码语言：</span>javascript</div></div><div class="rno-markdown-code-toolbar-opt"><div class="rno-markdown-code-toolbar-copy"><i class="icon-copy"></i><span class="is-m-hidden">复制</span></div></div></div><div class="developer-code-block"><pre class="prism-token token line-numbers language-javascript"><code class="language-javascript" style="margin-left:0">1）wetest是腾讯公司支持的通用压测方案，要用好也要对里面提供的设置了解清楚用法和用途。

2）测试不限于压测工具，本地脚本，浏览器network分析，线上用户test，等等都可以尝试用来评测分析。

1）上限设置

2）专用资源池
3）实例保持
4）架构升级（测试中）
5）就近接入（待规划）

1）代码逻辑和第三方调用

2）拆分不常用功能，减少代码量
3）使用预加载减少connect的时间（preconnect）
4）接入STGW进行转发