Web 应用程序的适当页面处理时间是多少？答案

【问题标题】：What is an appropriate page processing time for a web application?Web 应用程序的适当页面处理时间是多少？
【发布时间】：2011-03-07 17:08:52
【问题描述】：

我正在开发一个 Web 应用程序，它已经达到了我拥有大部分必要功能的地步，我开始担心执行速度。所以我四处寻找信息，我发现了很多关于通过缩小 CSS/JS、设置缓存控制标头、为静态文件使用单独的域、压缩输出等来减少页面加载时间的方法（以及基本的服务器 - memcached 等辅助技术）。但是假设我已经优化了这一切，我关心的是我的 Web 应用程序实际生成页面需要多长时间，即没有缓存命中的纯服务器端处理时间。显然，减少时间的技巧将取决于我使用的语言和底层库，但合理的目标是多少？作为比较，我会对使用现有框架构建的应用程序的处理时间的真实示例感兴趣，执行访问数据库和呈现模板等典型操作。

我使用了一些代码来测量处理时间（或者至少是我编写的代码中发生的部分时间），我通常看到的值在 50-150 毫秒之间，这似乎相当高.我很想知道我应该在多大程度上专注于降低它，或者我对这个应用程序的整个方法是否太慢，我应该放弃它并尝试一些更简单的东西。（基于 Firebug 的 Net 选项卡，考虑到我在同一台计算机上同时使用客户端和服务器进行测试，我未测量的处理部分通常添加不到 5 毫秒。）

仅供参考，我正在使用 Python，使用 Werkzeug 和 SQLAlchemy/Elixir。我知道那些不是最有效的技术，但我真的只关心足够快，而不是尽可能快。

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

更好的是，下面是 Firebug 的 Net 选项卡中的一个典型示例的屏幕截图：我要问的是顶部的 74 毫秒。

【问题讨论】：

标签： performance timing

【解决方案1】：

恕我直言，在大多数情况下，服务器端客户端的 50-150 毫秒是可以的。当我测量一些非常知名的网站的速度时，我很少看到有这么快的东西。大多数时候，它大约是 250 毫秒，通常更高。

现在，我想强调三点。

一切都取决于上下文。如果加载需要几秒钟，那么将非常频繁地访问的主页或页面会很糟糕。另一方面，如果优化成本太高，网站中一些很少使用的部分可能需要长达一秒钟的时间。
用户主要关心的是快速完成他们想要的。这与访问单个页面所花费的时间无关，而是访问信息或实现目标所花费的时间。这意味着让一个页面花费 250 毫秒要比要求用户一个接一个地访问三个页面来做同样的事情，每个页面花费 150 毫秒来加载要好。
注意感知的加载时间。例如，Stack Overflow 网站上使用了一个有趣的技巧。当做一些基于 AJAX 的事情时，比如向上/向下投票，首先你会看到效果，然后向服务器发出请求。例如，尝试对您自己的消息进行投票。它会显示消息已被投票（箭头将变为橙色），然后，200 毫秒后，箭头将变为灰色并显示错误框。因此，在投票的情况下，感知加载时间（箭头变为橙色）为 1 毫秒，而执行请求所花费的实际加载时间为 100 毫秒。

编辑： 200 毫秒也可以。如果页面被频繁访问或者用户期望页面很快（例如，AJAX 请求期望很快），500 毫秒可能会有点伤害。顺便说一句，我在屏幕截图中看到您使用了几个 CSS 文件和十个 PNG 图像。通过将combining CSS 放入一个文件并使用CSS sprites，您可能可以减少感知的加载时间，尤其是在处理网络延迟时。

【讨论】：

好点。你所说的关于精灵和组合 CSS 文件的内容肯定在我的“待办事项”列表中，但这并不是我要关注的问题。
@David Zaslavsky：我知道。这只是我注意到的一件事。这就是为什么我把它放在我的答案的最后。所以如果你愿意，我的回答是：1.你当前的页面处理时间相当不错，没有全局唯一的“合适的页面处理时间”。 2. 最终用户可能会有其他顾虑（完成目标的时间 + 感知时间）。
明白 ;-) 我想额外的建议永远不会有什么坏处——它当然不会降低你的回答质量。

【解决方案2】：

Jakob Nielsen，一位著名的可用性演讲者在几天前发表了一篇文章 [1]。他建议不到 1 秒就可以了，不到 100 毫秒是完美的，因为它会更多地中断用户流程。

正如其他用户所指出的，这取决于该页面的上下文。如果有人正在上传文件，他们预计会有延迟。如果他们正在登录并且需要十秒钟，他们就会开始感到沮丧。

[1]http://www.useit.com/alertbox/response-times.html

【讨论】：

【解决方案3】：

我查看了一些旧的 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 完美集成，并提供了有关如何加快页面加载速度的重要信息。

【讨论】：

+1 表示数据，这是我感兴趣的事情。（顺便说一句，我已经有 YSlow，但感谢您的提示）

【解决方案4】：

页面加载时间为 50-150 毫秒即可 - 此时您无需进一步优化。

事实是，只要您的页面在一秒钟内加载完毕，您就可以了。

请参阅this article，其中讨论了加载时间对转换的影响（亚马逊增加 100 毫秒 = 1%）。

【讨论】：