性能测试是发布新网站和新代码的重要环节。全面性能测试决定了发布的成功或失败。
在发布新网站和应用程序时,性能测试尤其重要,因为这时还没有任何关于应用执行性能的历史数据。应用程序框架、平台和硬件的新技术也可能会开始起作用。硬件的变化是很快的,而使用最新发布的硬件来运行应用程序,其性能可能比六个月前预定的硬件高很多。
性能测试应该尽早执行,新产品的所有组件都应该先进行测试,然后才能进行开发。如果新硬件的容量达到了遗留系统硬件容量的两倍水平,那么使应用架构产生相同性能的硬件需求就会少于过去开发的应用程序。
如果已经有一个可访问和正常运行的Web应用程序,那么先给新应用程序分配一小部分测试带宽(如果它将替代旧的应用程序),然后让最终用户试用新应用程序。这种“在生产环境中测试”的方法可以给我们提供一些非常宝贵的信息,从中可以了解当生产流量进人应用程序时它的执行情况。此外,我们也可以通过解析历史Web日志来模拟一些生产流量,将这些流量导入到新应用程序上,从而测试它在生产环境的运行性能。然而,这仍然属于一种合成测试,其测试结果肯定不同于公共互联网的真实测览器或客户端成用程序的真头流量的测试果。通过测量到达新应用程序的流量数量,或者将现有网站的一小部分用户导入到新应用程序中,我们就可以获得一些宝贵的信息,了解应用程序在正式发布和接收生产流量之后可能的执行情况。
1.本地性能测试
Web开发人员应该在专用服务器上创建Web应用程序实例,这个专用服务器要的硬件和环境配置都要跟新网站及其应用程序、数据库或数据存储将要使用的硬件和环境配置相类似。并不是每一位Web开发人员都能够创建一个与生产环境类似的环境。然而,重要的是他们有足够的可用资源,能创建最接近部署最终产品的生产环境。这可能意味着,Web开发人员要有一个塔式工作站,但是它的处理能力与运行生产网站的服务器相当。这样可以保证开发应用程序的环境尽可能接近最终的生产环境。
保证网站或应用程序性能接近客户所面对环境的另一种方法是,直接在一个与生产环境类似的测试环境上开发应用程序。这取决于快照时间表是否合理,以及目前有多少的试生产或分段环境,但是这样做可以节约很多时间,因为本地开发者工作站通常无法反映Web应用程序在生产环境的真实性能。
本地测试可以直接通过使用一些自动化工具或浏览器插件完成。最使用真实Web浏览器去测试Web应用程序性能,因为它能够更真实地反映网站的性能。大多数网站都是动态的,而JmeterI或ApacheBench等自动化合成测试工具无法呈现动态内容,如Javascript和CSs,而且它们会增加网站的响应时间。工具Hammerhead支持在Ficx浏览器中重复加载一个网页并清除缓存,从而可以帮助Web开发人员了解一个网页的加载时间。Firebug.则是另一个实用工具,它可以显示Web浏览器呈现一个网页所需要的时间,其中包括所有的动态内容。
如果本地测试发现页面加载时间为1~3秒,而且网站本身没有太多的图片,那么这个网站就可能有一些问题。大多数网民都没耐心,他们不愿意等待,特别是现在宽带已经非常普及,早不是拨号上网的时期,用户并不理解数据库需要先执行一些査询操作,然后才能呈现一个网页。所以,在测试Web应用程序时,如果渲染时间超过3秒钟,那么可能就要去掉一些需要加载的静态内容或所执行的前端操作数量
2.缓存
许多公司会错误地决定购买一个内容交付网络(CDN)。CDN通常是一种Web内容的反向代理,所以CDN公司会在各地配置Web服务器,它很像一个web性能监控公司。CDN不会在服务器上使用Web浏览器去定期测试网站的加载速度,而是将我们的网站服务器副本存储到全国或全世界各地。使用CDN的主要原因是因为Web服务器所在位置与用户所在位置不同,例如网站在加拿大多伦多,而用户从美国堪萨斯州威奇托市访问网站,所以网站加载时间就包括从多伦多到威奇托之间的数据加载时间。相反,CDN会使用一个Web服务器的反向代理将内容存到本地,所以当有人从威奇托访问网站时,返回响应的是CDN公司位于威奇托的服务器,而不是多伦多的原始服务器,这样就可以显著减少响应时间。
许多CDN公司现在都会在服务中附加一些Web性能最佳实践方法,如缩略或压缩Javascript、HTML和CSS内容的压缩技术,甚至再添加层Web应用程序安全抽象。这些都是非常适合生产网站的服务,它们可以提高网站设计的性能,但是在解决性能问题时,工程师必须謹慎使用这些“罐装”服务。缓存是一种加速和提升网站性能的好方法,但并不是一种修复性能问题的有效方法,我们应该在开发人员的本地工作站上解决性能问题。
>>> 查看《网站性能测试技巧》更多相关资讯 <<<
本文地址:http://weboss.link/news/html/4529.html