2

我有许多数据驱动的基于 Web 的应用程序，它们为内部和公共用户提供服务，并且想衡量您期望创建页面的速度（以毫秒为单位）以保持用户满意度和可扩展性。

那么，为了维护一个快速的网站，创建页面的速度有多快？

这些站点是在 ASP 经典中开发的，带有一个 SQL Server 后端，可以生成我使用 XSLT 呈现的 XML 记录集。不是最有效的技术，创建页面需要 7 毫秒到 120 毫秒（即第一行代码和“Response.Write”之间的计时器间隔），具体取决于页面的复杂性。较慢的页面是由于数据库运行更大和更复杂的查询。即使我将所有的 ASP 经典重写为 ASP.NET，整体页面渲染速度也不会有任何显着提高。

我经常听到 Jeff 说他希望 SO 成为最快的站点，并且他的博客已经讨论了他的代码和数据库的优化，但是您在优化代码方面需要走多远？通过使用 StringBuffer 而不是 String + String 来减少毫秒数是否可以很好地利用我的时间？

[澄清]

您从什么时候开始认为“此页面创建时间过长？”。是超过 20 毫秒、超过 200 毫秒还是一个页面可以花费一秒钟的时间来构建？你的“目标时间”是多少？

4

5 回答 5

5

这完全取决于您的受众和目标——我曾在目标“onload”事件<4secs的应用程序以及服务器上的时间预计<1ms的应用程序上工作。它可以采用任何一种方式 - 但无论您做什么，您都需要注意，无论您在服务器端级别进行的任何性能优化，都可能与网络性能（仍然是 Web 的主要瓶颈）和感知加载时间相形见绌。

雅虎对一般网站性能有一些很好的指导，特别是在感知负载方面。

希望您已经足够聪明，可以缓存您可以缓存的内容并做一些小事情，例如避免大量的 Response.Writes 链......

于 2009-05-07T09:34:23.753 回答
2

用户并不关心您准备数据的速度，他们只关心页面的实际加载时间。

如果您在渲染中有很多开销，您的用户将体验到您的网站速度很慢。关于经典的 ASP，字符串连接被认为是非常糟糕的做法，因为当您达到关键字符串长度时它会非常慢，这将开始成为服务器的负担。

使用数组 (jscript) 或 .NET StringBuffer 可以显着改善渲染时间。除了卸载不必要的 CPU 使用，这将允许您的服务器处理更多流量，我想说那些明显的优化是非常值得做的。

于 2009-05-07T09:30:55.150 回答
2

可以在此处找到有关此主题的非常有趣的截屏视频：链接文本。

Although it is made by a Rails guy, it is perfectly applicable to other frameworks.

于 2009-05-07T09:58:20.093 回答
0

如果您只需更改一件事就可以减少毫秒，那就去做吧！

您可能还想查看缓存数据库请求。

于 2009-05-07T09:29:18.367 回答
0

One factor that affects user satisfaction to server response time is how often he is requesting a new page. If you're presenting (say) a page with lots of information that the user is going to spend some time to read, a longer "rendering" time is okay. In contrast, if the person is quickly navigating through pages, he will want a near instantaneous response.

For example, if you're on a news site, you probably will be okay if it takes a full second or two for the next page, since you're going to be spending 30 seconds to read it.

On the other hand, if you're browsing through an interactive map, you probably want the response to be less than a second.

于 2009-05-07T10:18:57.780 回答