微信小程序使用cdn加速(微信小程序 加速)

本文目录：

• 1、<"http://#%E5%BE%AE%E4%BF%A1%E5%B0%8F%E7%A8%8B%E5%BA%8F%E4%BA%91%E5%BC%80%E5%8F%91%E4%B8%AD%E7%9A%84CND%E6%B5%81%E9%87%8F%E6%98%AF%E5%B9%B2%E5%98%9B%E7%9A%84%EF%BC%9F" title="微信小程序云开发中的CND流量是干嘛的？" "">微信小程序云开发中的CND流量是干嘛的？
• 2、<"http://#%E5%BE%AE%E4%BF%A1%E4%BC%A0%E5%A5%87%E5%B0%8F%E7%A8%8B%E5%BA%8F%E5%8F%AF%E4%BB%A5%E7%94%A8%E5%8A%A0%E9%80%9F%E5%99%A8%E5%90%97" title="微信传奇小程序可以用加速器吗" "">微信传奇小程序可以用加速器吗
• 3、<"http://#%E5%81%9A%E4%B8%80%E4%B8%AA%E5%BE%AE%E4%BF%A1%E5%B0%8F%E7%A8%8B%E5%BA%8F%E8%A7%86%E9%A2%91%E6%92%AD%E6%94%BE%E7%B1%BB%E7%9A%84%EF%BC%8C%E5%A6%82%E4%BD%95%E6%8F%90%E5%8D%87%E8%A7%86%E9%A2%91%E5%8A%A0%E8%BD%BD%E9%80%9F%E5%BA%A6" title="做一个微信小程序视频播放类的，如何提升视频加载速度" "">做一个微信小程序视频播放类的，如何提升视频加载速度
• 4、<"http://#%E8%AE%B0%E4%B8%80%E6%AC%A1%E5%BE%AE%E4%BF%A1%E5%B0%8F%E7%A8%8B%E5%BA%8F%E9%A1%B5%E9%9D%A2%E5%8A%A0%E8%BD%BD%E6%85%A2%E7%9A%84%E6%8E%92%E6%9F%A5%E8%BF%87%E7%A8%8B" title="记一次微信小程序页面加载慢的排查过程" "">记一次微信小程序页面加载慢的排查过程

微信小程序云开发中的CND流量是干嘛的？

微信小程序云开发中的新的流量是用来进行大数据缓存的，是针对科技公司来使用的，个人无法使用

微信传奇小程序可以用加速器吗

可以，但是不建议使用加速器，因为微信传奇小程序是一款模拟器游戏，使用加速器会导致游戏出现卡顿、断线等问题，影响游戏体验。

做一个微信小程序视频播放类的，如何提升视频加载速度

这样的一般是服务器那边的问题，在选择服务器内存，贷款以及机房上面都需要进行评估，不是随随便便选择的。

记一次微信小程序页面加载慢的排查过程

公司新上线了一个微信小程序，在测试环境以及小程序体验版上测试一切正常，但上线之后，页面加载尤其慢。

经过运维排查，所有的请求到达服务器后均在1s内处理完成并响应，偶尔有2-3s的请求，极少。

既然服务端处理请求没有问题，那么，加载可能出现在小程序本身或网络延迟，但后者可能性较低。于是，使用fiddler抓包，其中一个加载较慢的请求结果如下：

关键时间节点如下：

· 客户端与服务器完成tcp链接时间是11:31:35（时分秒）

· 客户端开始向服务端发送请求的时间是11:31:36（时分秒）

· 服务端接收到请求的时间是11:31：36（时分秒）

· 服务端开始响应的时间是11:31:46（时分秒）

也就是说，从服务器接收到请求到开始响应耗时10s，可这跟运维查看的日志结果不符！

鉴于上面的抓包结果和生产日志结果相悖，决定使用curl对耗时较长的http请求进行分析。

运行结果如下

对应的结果含义如下：

· time_namelookup ：DNS 域名解析的时候，就是把 转换成 ip 地址的过程

· time_connect ：TCP 连接建立的时间，就是三次握手的时间

· time_appconnect ：SSL/SSH 等上层协议建立连接的时间，比如 connect/handshake 的时间

· time_redirect ：从开始到最后一个请求事务的时间

· time_pretransfer ：从请求开始到响应开始传输的时间

· time_starttransfer ：从请求开始到第一个字节将要传输的时间

· time_total ：这次请求花费的全部时间

那么对应的时间点应该是：

· DNS解析耗时：0.005s

· TCP建立连接的耗时：0.035-0.005=0.03s

· SSL握手完成耗时：3.8-0.034=3.7s

· server处理数据的时间：3.8402-3.8401=0.0001s

· 总体的耗时：14.5s

emmm，按照这个结果来看，从服务器开始响应到传输完成一共耗时14.5-3.8=10.7s。

那么这里问题又来了，这结果跟fiddler的结果完全相反，到底是在哪个环节出了问题？

fiddler的结果显示从服务器接收到请求到开始响应耗时10s，是服务器处理请求消耗了10s；而curl显示服务器处理请求只用了0.0001s，响应开始到结束耗时10.7s。到底哪个是对的，难道是根据本身有问题？

于是在跟运维同事一波交流之后，得到请求流转过程如下：

客户端----------CDN服务器----------Nginx代理----------应用服务器----------DB

弄清请求流转过程之后，手动发送请求，实时查看Nginx和应用服务器日志，发现请求发出后，间隔一段时间（10s左右）Nginx日志才有输出，接着很快App Server日志也有输出（包括请求和响应）。事实就摆在眼前，是CDN服务器----------Nginx代理之间出现了问题，具体是为什么目前还不清楚。

那么fiddler和curl抓包的结果如何解释？

fiddler：从服务器接收到请求到开始响应耗时10s，是正确的。

curl：服务器处理请求只用了0.0001s，响应开始到结束耗时10.7s。这里就有问题了，要想解释得通，只能说time_pretransfer和time_starttransfer是CDN服务器的响应时间，由于配置了CND，在向小程序应用服务器发送请求时，会先请求到CDN服务器此时CDN服务器很快就响应了客户端的请求，但CDN服务器在转发请求到Nginx代理时出现了延迟，因此在curl的请求结果中才会看起来像是响应开始到响应结束耗时较长。

至于为什么请求从CND服务器到应用服务器会出现延迟，目前还没有结论。待更新

【微信小程序使用cdn加速】内容来源于网络，若引用不当、侵权，请联系我们修正或者删除！