为什么重复的GET请求变慢了?-创新互联

最近在研究慢请求监控的问题,写了一个简单的测试代码:在网页端(index.html)通过fetch函数向服务端获取数据,然后打印请求耗时。

成都创新互联服务紧随时代发展步伐,进行技术革新和技术进步,经过10年的发展和积累,已经汇集了一批资深网站策划师、设计师、专业的网站实施团队以及高素质售后服务人员,并且完全形成了一套成熟的业务流程,能够完全依照客户要求对网站进行成都网站制作、做网站、建设、维护、更新和改版,实现客户网站对外宣传展示的首要目的,并为客户企业品牌互联网化提供全面的解决方案。
function requestData() {
    let start = new Date();
    fetch("http://localhost:3000/company/basic")
        .then(res => {
            return res.json();
        })
        .then(res => {
            let span = new Date() - start;
            console.log("span:", span);
        });
}
requestData();

在服务端通过setTimeout延时1500s才返回数据(服务端使用ExpressJS)。

app.get("/company/basic", (req, res) => {
    setTimeout(function() {
        res.send({ hello: "Hello Fundebug!" });
    }, 1500);
});

不出所料,span数据都略微大于 1500。

而后,我突发奇想,假设我同时发送多个请求会怎么样呢?于是有了如下代码:

[1, 2, 3].forEach(function() {
    requestData();
});

结果好像也没问题,在 Chrome 浏览器下面是这个效果:

为什么重复的GET请求变慢了?

接入 Fundebug 慢请求监控测试

于是愉快地接入 Fundebug 监控:

并设置如果请求时长超过 2 秒就上报:

if ("fundebug" in window) {
    fundebug.httpTimeout = 2000;
}

本以为刷新页面,应该不会收到报错。

结果,万万没想到的是,Fundebug 收到 2 个慢请求报错。

为什么重复的GET请求变慢了?

这不科学啊!

点开错误详情,可以看到具体的报错信息。一个请求耗时 3018 毫秒,一个请求耗时 4525 毫秒。

为什么重复的GET请求变慢了?

也就是说,第一个请求没问题,假设是 1500 毫秒。我们把三个请求的时间放一起看看有何规律:1500,3018,4524。他们近似成等差数列,相差 1500 毫秒。于是,我怀疑三个请求是一个一个阻塞式的,而不是并发的。

测试并发请求不同 API 的情况

为了验证这一点,我将测试改为请求三个不同的 API 接口。

服务端代码:

app.get("/company/basic", resp);
app.get("/company/basic1", resp);
app.get("/company/basic2", resp);

function resp(req, res) {
    setTimeout(function() {
        res.send({ hello: "Hello Fundebug!" });
    }, 1500);
}

网页端代码(requestData函数传入请求的 URL):

[
    "http://localhost:3000/company/basic",
    "http://localhost:3000/company/basic1",
    "http://localhost:3000/company/basic2"
].forEach(function(item) {
    requestData(item);
});

为了获取请求数据,将httpTimeout改为 1500。

if ("fundebug" in window) {
    fundebug.httpTimeout = 1500;
}

Fundebug 捕获三个请求的时间,分别为 1526,1525,1529。

为什么重复的GET请求变慢了?

至此大体验证了刚刚的假设:对同一个 API 接口的并发请求会被阻塞,对不同的 API 接口并发请求正常执行。

那么为什么会被阻塞呢?意图何在?接下来慢慢给各位介绍。

背后的原因

在StackOverflow上找到了答案:

Yes, this behavior is due to Chrome locking the cache and waiting to see the result of one request before requesting the same resource again. The answer is to find a way to make the requests unique.

也就是说,Chrome 特意做了这样的设计。对于连续的相同请求,Chrome 会阻塞后面的请求,直到前面的完成。通过判断前面的请求返回的 Header 里面的缓存设置来决定下一步的行动。

我们可以做个实验来验证一下。

缓存实验

  • 服务端设置缓存 2 秒

    在服务端的接口返回代码中配置缓存时间

    res.setHeader("Cache-Control", "public, max-age=2");

    为什么重复的GET请求变慢了?

  • 服务端设置不缓存

    res.setHeader(
      "Cache-Control",
      "private, no-cache, no-store, must-revalidate"
    );

    为什么重复的GET请求变慢了?

  • Chrome 开发者面板设置Disable Cache

    为什么重复的GET请求变慢了?

最后的疑问

为什么打开和不打开谷歌开发者控制台,行为会不一样了?

其实是有原因的,而且这个干扰项一度成功阻止了我发现问题的本质。当我们在开发前端项目的时候,代码的改动希望能够实时地反应到网页上,而不是受到浏览器缓存的影响,但是我们发现往往刷新页面的时候没有真的去服务端获取数据,还是老的信息。于是,我们会去配置一个选项,将Disable Cache设置为true。也就是说,在开发环境下,缓存是被禁用了的,也就不存在等待第一个请求返回然后判断其 Header 里面Cache-Control设置的问题。这也是为什么打开谷歌开发者控制台,请求没有等待,立即执行了。

关于Fundebug

Fundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线,Fundebug累计处理了10亿+错误事件,付费客户有阳光保险、核桃编程、荔枝FM、掌门1对1、微脉、青团社等众多品牌企业。欢迎大家免费试用!

为什么重复的GET请求变慢了?

版权声明

转载时请注明作者 Fundebug以及本文地址:
https://blog.fundebug.com/2019/07/17/chrome-stall-multiple-same-request/

另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。


分享题目:为什么重复的GET请求变慢了?-创新互联
文章来源:http://myzitong.com/article/djpphh.html