代码之家 › 专栏 › 技术社区 › David Z

Web应用程序的适当页面处理时间是什么?

timing performance

David Z · 技术社区 · 14 年前

我正在开发一个Web应用程序,它已经到了我拥有大部分必要功能的地步,我开始担心执行速度。因此,我四处寻找信息,发现通过缩小css/js、设置缓存控制头、为静态文件使用单独的域、压缩输出等(以及基本的服务器端技术,如memcached),可以减少页面加载时间。但是假设我已经优化了所有这些,我关心的是我的web应用程序生成一个页面实际需要多长时间,也就是说,没有缓存命中的纯服务器端处理时间。显然,缩短时间的技巧将取决于我使用的语言和底层库,但是要达到的合理目标是什么呢?相比之下,我对现实世界中使用现有框架构建的应用程序的处理时间示例很感兴趣,比如访问数据库和呈现模板。

我用一点代码来测量处理时间(或者至少是我写的代码中发生的那部分时间),我通常看到的值在50-150ms之间,这看起来相当高。我很感兴趣的是,我应该把精力集中在如何减少这种情况上,或者我对这个应用程序的整个方法是否太慢,我应该放弃它,尝试一些更简单的方法。(基于Firebug的net选项卡,考虑到我在同一台计算机上使用客户机和服务器进行测试,我不测量的处理部分通常添加不到5毫秒。)

仅供参考,我正在使用werkzeug和sqlacchemy/elixir在python中工作。我知道这些不是最有效的技术,但我只关心足够快,而不是尽可能快。

编辑 :只是澄清一下,我上面引用的50-150ms纯粹是服务器端处理时间, 只是对于HTML页本身。如用户所见,页面加载所需的实际时间至少为200毫秒。 较高的 (所以,总共250-350毫秒)因为CSS/JS/Images的访问时间(尽管我知道通过正确使用缓存和 Expires 头、精灵等,这是我在不久的将来要做的事情)。除此之外,网络延迟还会增加更多的时间,因此我们可能会讨论总客户机加载时间的500毫秒。

更好的是,下面是Firebug的net选项卡中的屏幕截图,例如: Loading times from Firebug http://www.ellipsix.net/ext-tmp/loadtimes.png 我要问的是顶部的74毫秒。

4 回复 | 直到 14 年前

Arseni Mourzenko 14 年前

imho,在大多数情况下,服务器端的客户机端50-150 ms是可以的。当我测量一些知名网站的速度时,我很少看到这么快的东西。大多数情况下,约为250 ms,通常更高。

现在,我想强调三点。

一切都取决于上下文。如果需要几秒钟的时间来加载,那么经常访问的主页或页面将非常糟糕。另一方面,如果优化成本很高,网站中一些很少使用的部分可能需要一秒钟的时间。
用户最关心的是快速完成他们想要的。这不是花在 访问单个页面 但不是时候 访问信息 或 实现目标 . 这意味着一个页面占用250毫秒要比要求用户一个接一个地访问三个页面做同样的事情要好,每个页面占用150毫秒。
注意感知的加载时间。例如,在堆栈溢出网站上使用了一个有趣的技巧。在做基于Ajax的事情时,比如上下投票, 第一您看到效果,然后向服务器发出请求。例如,尝试向上投票您自己的消息。它将向您显示消息已被向上投票(箭头将变为橙色)。然后 ,200 ms后,箭头将变为灰色,并显示一个错误框。所以在投票结果上升的情况下, 感知负载时间 (箭头变为橙色)为1 ms,此时执行请求所花费的实际加载时间为100 ms。

编辑: 200毫秒也可以。如果频繁访问页面或用户期待页面要快速(例如,Ajax请求预期快一点。顺便说一下,我在屏幕截图上看到您正在使用几个CSS文件和十个PNG图像。通过 combining CSS into one file and using CSS sprites 您可能会减少感知的加载时间,尤其是在处理网络延迟时。

tooba 14 年前

JakobNielsen,一位著名的可用性演讲者,几天前发表了一篇文章[1]。他建议在1秒钟内就可以了,100毫秒以下是完美的,因为它会稍微中断用户流。

As other users have pointed out it depends on the context of that page. If someone is uploading a file they expect a delay. 如果他们登录需要10秒钟,他们可能会开始感到沮丧。

〔1〕 http://www.useit.com/alertbox/response-times.html

Lauri Lehtinen 14 年前

我查看了一些旧的JMeter结果,这些结果是在我编写和运行一套针对Web服务的性能测试时得到的。我会在下面附加一些,当然不是苹果和苹果,而是至少另一个数据点。

时间以毫秒为单位。 Location Req 和 Map Req 固有延迟分别为15000和3000毫秒。 Invite 包括快速呼叫移动运营商的LDAP服务器。其他的是相当标准的,主要是数据库读/写。

sampler_label    count    average    min    max
Data Blurp       2750     185        30     2528 
UserAuth         2750     255        41     2025
Get User Acc     820      148        29     2627
Update User Acc  4        243        41     2312
List Invitations 9630     345        47     3966
Invite           2750     591        102    4095
ListBuddies      5500     344        52     3901
Block Buddy      403      419        79     1835
Accept invite    2065     517        94     3043
Remove Buddy     296      411        83     1942
Location Req     2749     16963      15369  20517
Map Req          2747     3397       3116   5926

这个软件运行在一个专用的、像样的虚拟机上,与生产虚拟机的调优方式相同。这个 max 结果很慢,我的目标是找到我们可以支持的并发用户的数量,所以我在推它。

我觉得你的电话号码完全没问题。至于其他所有让网站看起来很慢的东西,如果你没有,看看 YSlow . 它与Firebug很好地集成,并提供了有关如何使页面加载更快的重要信息。

Oded 14 年前

页面加载时间为50-150ms是可以的-此时不需要进一步优化。

事实上,只要你的页面在一秒钟内加载,你就可以了。

见 this article 其中讨论了转换的加载时间的影响(对于Amazon,加载时间增加100毫秒=1%)。