我有一些基于数据的网络应用程序,可以为内部和公共用户提供服务,并希望衡量您希望创建页面的速度(以毫秒为单位),以保持用户满意度和可扩展性。
那么,创建页面以保持快速站点的速度有多快?
网站是用ASP经典开发的,SQL Server后端生成我使用XSLT渲染的XML记录集。不是最有效的技术和页面需要7ms到120ms来创建(即第一行代码和'Response.Write'之间的定时器间隔),具体取决于页面的复杂性。较慢的页面是由于数据库运行更大和更复杂的查询。即使我将所有ASP经典版重新编写到ASP.NET中,整个页面渲染速度也不会有任何显着的改进。
我经常听到Jeff说他希望SO the fastest site,他的博客讨论了他的code和数据库的优化,但是你需要在优化代码方面走多远?通过使用StringBuffer而不是String + String来缩短毫秒时间可以很好地利用我的时间吗?
[澄清]
你在什么时候开始思考“这个页面创建时间太长了?”。是超过20毫秒,超过200毫秒还是一个页面可以接管一秒钟构建?你的“目标时间是多少?”
答案 0 :(得分:5)
这完全取决于您的受众和目标 - 我已经使用&lt; 4secs上的目标'onload'事件的应用程序,以及服务器上的时间预计<1ms的应用程序。它可以采用任何一种方式 - 但无论你做什么,你都需要注意,无论你在服务器端进行的任何性能优化都可能与网络性能,网络的主要瓶颈以及敏感的加载时间相比都相形见绌。
雅虎有一些excellent guidelines用于一般网站的表现,尤其是在感知负载区域。
希望你已经足够聪明,可以缓解你所能做的事情并做一些小事,比如避免大量的Response.Writes ......
答案 1 :(得分:2)
用户不关心您准备数据的速度,他们只关心页面的实际加载时间。
如果您在渲染方面有很多开销,那么您的用户会觉得您的网站速度很慢。关于经典的ASP,字符串连接被认为是非常糟糕的做法,因为当你达到关键的字符串长度时,它将会非常慢,它将开始成为服务器的负担。
使用数组(jscript)或.NET StringBuffer可以显着缩短渲染时间。除了卸载不必要的CPU使用率,这将允许您的服务器处理更多的流量,我会说这种明显的优化非常值得做。
答案 2 :(得分:2)
有关此主题的非常有趣的截屏视频可在此处找到:link text。
虽然它是由Rails人员制作的,但它完全适用于其他框架。
答案 3 :(得分:0)
如果只需改变一件就可以减少毫秒数,那就去吧!
您可能也希望了解缓存数据库请求。
答案 4 :(得分:0)
影响用户对服务器响应时间满意度的一个因素是他请求新页面的频率。如果您正在呈现(说)一个包含大量信息的页面,用户将花一些时间阅读,那么更长的“渲染”时间就可以了。相反,如果这个人正在快速浏览页面,他将需要近乎即时的响应。
例如,如果您在新闻网站上,如果下一页需要一两秒钟,您可能会好起来,因为您将花30秒钟阅读它。
另一方面,如果您正在浏览交互式地图,您可能希望响应时间不到一秒。