技术改变世界 阅读塑造人生! - shaogx.com

This string was altered by TechBlog\Plugins\Example.; This is an example to show the potential of an offcanvas layout pattern in Bootstrap. Try some responsive-range viewport sizes to see it in action.

JMeter 服务器性能监测插件介绍

简介压力测试过程中,能够随时对负载服务器的健康状况的把控是相当重要的,有了这些数据,我们才能准确分析出服务器负载瓶颈。当你面对的是一个集群的时候,如果能了解到负载是否被正确分发,是不是一件很棒的事情?为了达到这些目的,JMeter 插件包现在能够支持服务器监控啦!使用这个插件,你几乎可以在所有平台上对服务器的 CPU、内存、Swap、磁盘 I/O、网络 I/O 进行监控!以下监控插件截图演示了压力测试中的 4 台服务器的 CPU 使用情况:支持指标统计版本 0.5.0 之后 JMeter 的服务器代理工具能够支持到 75 项系统指标。参见详细列表。工作原理概念JMeter 无法提取除 Tomcat 之外的其他服务器的默认指标。为了克服这一状况,我们研发了一个服务器代理,JMeter 通过这个代理来获取性能数据。这个代理使用的是 SIGAR 开源库,它是由一个 Java 通用部分和一个每个 OS 的本地库组合而成。安装服务器代理工具详情描述参见 http://jmeter-plugins.org/wiki/PerfMonAgent。用法GUI 模式GUI 模式下,只需要添加服务器性能监控监听器,定义服务器列表以及要监控的指标类型,确保代理正常运行在远程服务器上并且没有被防火墙封锁,然后就可以运行测试了。数据将会在实时图表中显示。非 GUI 模式如果你在非 GUI 模式下跑 JMeter(参考博客《使用非 GUI 模式运行 JMeter 压力测试》),并且想把监控数据保存到一个文件中,只需在 GUI 中为服务器性能监控监听器配置好要输出到的结果文件即可,就像你为其他监听器所配置的那样。压力脚本运行结束之后,你就可以把保存的文件拖到 GUI 并查看图形数据了。JMeter 属性jmeterPlugin.perfmon.interval - 指标收集时间间隔,单位是毫秒jmeterPlugin.perfmon.useUDP - 值为 true 或 false,在 TCP 连接失败后是否尝试 UDP 连接在线查看你的性能数据Loadosophia.org 有个 feature,通过它,你可以在一个精彩的 Web 接口中查看你收集的性能数据。这是一个使用示例。原文链接:http://jmeter-plugins.org/wiki/PerfMon/。... 全文

JMeter 服务器性能 性能监控 性能监测 JMeter监控服务器性能指标

构建高性能ASP.NET站点 第五章—性能调优综述(后篇)

构建高性能ASP.NET站点第五章—性能调优综述(后篇)    前言:本篇主要讲述如何根据一些简单的工具和简单的现象来粗布的定位站点的性能问题。 本章的议题如下:性能调优的一般过程利用分析工具分析页面加载信息利用分析工具分析性能瓶颈      利用分析工具分析性能瓶颈    在上一节中,讲述了如何使用Firebug来生成页面加载信息的瀑布图,同时也讲述了使得页面加载变慢的四个大的问题:1.       服务端花费大量时间解析.aspx时间过长。2.       在服务端和浏览器之间,传递html时间过长3.       图片和flash文件的加载时间过长4.       Js和css的加载花费时间过长    那么我们下面就根据瀑布图来判断:页面加载变慢,到底是因为哪个因素导致的。 1.       如何判断:服务端花费大量时间解析.aspx时间过长。在下面的图示中,大家可以看到第一条时间线特别的长:其中紫色的那段表明了在浏览器接受到该页面的第一个字节之前等待的时间。也就是说,在浏览器请求Default.aspx页面之后,浏览器一直处于等待状态。只有浏览器接受到了Default.aspx的DOM之后,才开始下载页面中的其他的资源(css,图片等)。如果在接受Default.aspx的DOM之前等待的时间过长,那么势必影响其他的资源的下载,最后导致整个页面的加载变慢。 如果我们在用firebug生成瀑布图的时候,发现了上面的类似的现象,页面加载变慢的原因很有可能就是服务端在解析Default.aspx页面,生成html文本的时间太长了。至于是什么原因导致了服务端解析Default.aspx时间过长,那么需要进一步的分析。可能是代码写的不好,例如循环问题;可能是数据库问题,例如查询数据太慢或者数据太多等(后续文章详细讲述)。   注:颜色表示的意思:  2.       如何判断:在服务端和浏览器之间,传递html时间过长    在下面的图中,大家可以看到紫色的线段比较的短,也就是说,服务端解析Default.aspx页面的时间还是比较短的,但是灰色的线段比较的长,。灰色的部分表示接受数据时间很长,也就是说服务端把DOM发送到浏览器,这个过程耗时比较的长。正如之前的问题一样,这个问题也会推迟页面的其他的资源下载,导致整个页面加载过慢。导致这个问题的原因可能是带宽问题,可能是数据过多等。 3.       如何判断:图片和flash等文件的加载时间过长如下图所示,页面的解析和传送到客户端的时间比较的短,但是页面中的图片加载花费了大量的时间。现在的浏览器一般都会同时打开多个链接,并行的请求多个图片资源,而不是一个个的挨个请求。但是浏览器打开链接的数量是有限制的(不同的浏览器不一样),而且打开新的TCP链接也是需要花时间的,不是链接越多越好。后面我们会讲述如何减少图片等资源的加载时间。 4.       如何判断:Js和css的加载花费时间过长,阻止页面的呈现    如下图所示,在Default.aspx页面载入之后,浏览器就开始解析DOM(从上到下解析,例如head -> body…),下载资源。当页面解析到需要加载css和js时,此时浏览器就会去服务端请求这些文件,而用户在浏览器中看到的Default页面将会是一片空白,一直到css和js载入完成之后,页面开始下载图片等,此时页面才会慢慢的呈现出来。下图就反应了这个问题。       今天就到这里了,从下一篇文章开始就全面进入分析和调优阶段。本文出自 “燕洋天” 博客,请务必保留此出处http://yanyangtian.blog.51cto.com/2310974/490821 var kevent = 'onabort|onblur|onchange|onclick|ondblclick|onerror|onfocus|onkeydown|onkeypress|onkeyup|onload|onmousedown|onmousemove|onmouseout|onmouseover|onmouseup|onreset|onresize|onselect|onsubmit|onunload'; var aevent = kevent.split('|'); jQuery('.showContent img').each(function(){ var nimg = this; jQuery.each(aevent, function(i, n){ if (n!='onload') { jQuery(nimg).attr(n, ''); } else { if (jQuery(nimg).attr(n) != 'if(this.width>650) this.width=650;') { jQuery(nimg).attr(n, ''); } } }); }); var encodetitle = encodeURI('一篇很棒的博文分享给大家:《构建高性能ASP.NET站点 第五章—性能调优综述(后篇)》'); function show51share(){ window.open('http://t.51cto.com/index.php?m=share&url=http://yanyangtian.blog.51cto.com/2310974/490821&type=l&count=&relateUid=&appkey=3843950324&title=' + encodetitle); } window._bd_share_config={"common":{"bdSnsKey":{"tsina":"2065779340"},"bdText":"","bdMini":"2","bdMiniList":false,"bdPic":"http://blog.51cto.com/img/blog_down0731.jpg","bdStyle":"1","bdSize":"32"},"share":{}};with(document)0[(getElementsByTagName('head')[0]||body).appendChild(createElement('script')).src='http://bdimg.share.baidu.com/static/api/js/share.js?v=89860593.js?cdnversion='+~(-new Date()/36e5)]; beelzebub1人 了这篇文章 类别:构建高性能ASP.NET站点 ┆阅读(0)┆评论(0) ┆ 返回博主首页返回博客首页 上一篇 建高性能ASP.NET站点 第五章—性能调优综述(.. 下一篇 构建高性能ASP.NET站点 第六章—性能瓶颈诊断..相关文章SQL Server 性能优化中的几个见解普遍存在的网站性能问题对性能优化的一点思考Red Hat Enterprise Linux 4 服务器性能优化Linux系统中一些针对文件系统的节能技巧Flex编程注意之性能优化、垃圾回收的一些总结Oracle性能优化技巧建高性能ASP.NET站点 第五章—性能调优综述..本文收录至博客专题:《构建高性能 ASP.NET 站点》... 全文

构建高性能ASP.NET站点 性能优化 性能瓶颈分析 休闲 职场

性能调优概述

性能调优无疑是个庞大的话题,也是很多项目中非常重要的一环,性能调优的难做是众所周知的,毕竟性能调优涵盖的面实在是太多了,在这篇blog中我们蜻蜓点水般的来看看性能调优这项庞大的工程都有些什么过程,同时也看看这些过程中常见的一些做法。确定性能调优的目标... 全文

性能测试协商 性能测试 性能调优 TPS

性能优化攻略

为什么程序总是那么慢?它现在到底在干什么?时间都花到哪去了?也许,你经常会抱怨这些问题。如果是这样,那说明你的程序出了性能问题。和功能性问题相比,性能问题在有些情况下,可能并不算太大的问题,将就将就,也就过去了。但是,严重的性能问题会导致程序瘫痪、假死,甚至崩溃。看懂程序的性能a.执行速度  程序的反应是否迅速,响应时间是否足够短。b.内存分配  内存分配是否合理,是否过多地消耗内存或者存在泄露。c.启动时间   程序从运行到可以正常处理业务需要花费多少时间。... 全文

性能优化 性能指标 性能瓶颈 木桶原理 Amadahl定律

性能测试一般过程与LR性能测试过程

性能测试作为测试分类的一个大类,等同于系统测试中的功能测试、安全性测试和配置测试等,因此她的测试过程是对整个测试类型中测试过程的一个描述,因此包含了测试需要的确认目标,熟悉系统、获得需求等部分,因此性能能测试(performance testing)的测试一般过程如下:1)制定目标和分析系统2)获得需求3)设计性能测试用例4)通过协议模拟系统操作5)设计场景运行测试用例6)监控系统指标7)分析策四结果... 全文

性能测试 测试过程 LR性能测试

性能测试知多少:性能分析与调优的原理

最近一直纠结性能分析与调优如何下手,先从硬件开始,还是先从代码或数据库。从操作系统(CPU调度,内存管理,进程调度,磁盘I/O)、网络、协议(HTTP, TCP/IP ),还是从应用程序代码,数据库调优,中间件配置等方面入手。... 全文

性能测试 性能调优 测试

Web应用软件性能测试指南

本书详细地介绍应用软件性能测试的相关知识。本书共分为8个部分:第一部分“性能测试简介”,包括3章,分别介绍Web应用软件性能测试的基础知识、性能测试的各种类型以及通过性能测试可以揭示出的风险。第二部分“典型性能测试方法”,包括4章,分别介绍Web应用软件性能测试的核心活动、采用基于迭代的过程来调整性能测试、管理敏捷性能测试周期以及在可调控的(CMMI)环境中管理性能测试周期。第三部分“确定测试环境”,包括1章,介绍如何评估系统以提高性能测试的效率。... 全文

Web性能测试 软件性能测试 性能测试 Web应用测试

j2ee性能调优之最小化资源压力测试法则

摘要:我提倡使用最小化资源的方式做一次压力测试,排除大部分浅显的应用问题。最小资源的意思,即在pc环境,使用应用可以运行的最小资源状态下,进行压力测试和性能问题侦测的工作。前面看到有人讲j2ee的性能调优,虽然这块不是自己的专长,但是猪养多了,也忍不住跳出来说几句。虽然几乎每本讲性能调优的书籍开篇都会提,没必要的情况下就不要做调优,但是我个人还是认为,所有系统在上线前,都应该做一次基本的压力测试并对相关的性能问题进行检测, 但是迫于资源压力,很多项目都无法做正规的压力测试,一直到系统上线出现问题,才倒回来找原因。 而正规的压力测试,往往因为需要严格模拟生产环境,需要耗费大量的资源,各类专家配合解决问题,并不是那么轻松的可以做下来的。而j2ee应用的特点就是以复杂性来回避传统问题,所以任意一个j2ee的部署,相对于php那样的结构都是比较复杂的。系统一旦发生性能问题,必须在程序、数据库、应用服务器、jvm、操作系统几大块中交叉进行考虑,根据实际情况问题,问题的原因可能异常复杂。我们可以想象一个项目,从来不做UT不做IT ,只做一次UAT,然后直接提交给用户上线以后,修补错误的困难度和成本。经常看到一些调优的最后解决方案,可以肯定,几乎80%以上都是一些低级的程序错误导致的,剩下的20%虽然可能是用硬件,os参数调整等等问题解决了,但是其中很大一块,归根到底也是程序的问题。 而在我们回顾这些错误的时候可以很惊人的发现,大部分都是一些低级错误。我提倡使用最小化资源的方式做一次压力测试,排除大部分浅显的应用问题。最小资源的意思,即在pc环境,使用应用可以运行的最小资源状态下,进行压力测试和性能问题侦测的工作。这种做法的优点如下。1. 环境容易搭建, 特别是不需要考虑大型硬件和网络条件等等,也回避了开发人员可能不熟悉unix和特定应用服务器等问题2. 不需要特别的数据库,操作系统和应用服务器专家配合,开发人员自身即可完成。3. 不需要特别的依赖os和应用服务器,jvm的监测工具。选择自己最熟悉的即可。4. 开发人员在熟悉这种过程以后,再转到正式的生产环境工作时也更有经验,更容易解决问题。对测试过程做一点简单介绍。工具准备:得益于开源技术的发展,大部分工具都可以免费获得,使用也比较简单。1. jvm 监控: 对jvm的运行状态进行分析, 可以使用jvm自身带的特性输出日志,结合hp的jmeter profile进行分析。也可以使用jrockit自带的图形化工具mession control。熟悉什么用什么,越简单越好,目的主要是观察内存堆的变化,线程资源变化,gc情况等。2. 数据库监控工具: 熟悉数据库的使用数据库自身的特性,不熟悉的可以使用第三方工具,主要目的是观察数据库的锁,连接数信息, 对于db2我比较喜欢使用quest central。 oracle使用OEM或者自身的数据字典已经可以。3. 应用服务器监控: 主要目的是记录方法的调用情况和执行时间 ,找出频繁调用的方法和执行时间过长的方法。使用jprobe和jprofile都可以很轻松的做到。 如果使用的应用服务器比较偏门,那么可以换一个支持这种检测工具的应用服务器。反正主要目的只是在找问题。4.  sql执行监控:跟踪找出执行时间过长的sql。 我喜欢使用p6spy。5. 压力工具: jmeter+badboy , 有条件的可以用loadrunner, 和loadrunner近似的还有一个免费的开源产品。 另外web 应用的话, 也可以使用selenium这样的ff扩展来做。微软vs自带的也不错,反正是什么简单用什么。6. 记录表格: 对问题和资源配置的变更进行记录和对比。 我发现有些人做压力测试,只用压力工具来跑,不肯用各类proile工具来跟踪应用和数据库使用情况,加上经验又不足,结果测来测去都是瞎猜。设置:1. 数据库: 如果未使用连接池, 则尽可能的将数据库允许连接设置成最小数字,推荐是从1开始。如果使用连接池,则设置为1.随着并发模拟数的增加也可以适当上调,但是一定要低于压力工具模拟的并发用户数。数据库环境尽可能接近生产环境,至少要有足够的测试数据。2. 应用服务器: 对jvm启动堆做最小化设置。比应用服务器要求的最低内存略高,保证应用可以正常启动即可。根据模拟用户数增加可以小步适当上调,但是以保证应用基本运行即可。千万别来大内存。3. 压力模拟并发数,从1开始逐步往上加。一次加1,2个,上限不要太高,5-10个足以。 步骤1. 按1用户1连接的方式进行检测* 找出系统是否存在明显的资源泄露,比如数据库连接,如果存在泄露此种情况下服务器很容易就hold。* 找出执行时间过长的java方法和sql。进行分析修改。* 找出那些调用过多的方法和sql,对程序进行分析,看是否做了不必要的调用。 这个问题尤其在使用了第三方包的情况下要小心,我曾经监测出某人写的东西一个方法间接的调用了数据库操作近200次。有些人做测试喜欢从5以上的数字开始,实在不是什么好习惯,比较明显的问题都容易回避了。... 全文

性能测试协商 性能测试 j2ee 性能调优

高效云应用性能管理(APM)妙招尝鲜

在云上成功采用应用性能管理(APM)涉及几个关键的步骤:设置资源边界,限制性能变量;对云情况应用监控实践;在直接资源不能解决体验质量(QoE)问题时,部署补偿措施。首先介绍一下定义:APM是一种监控流程,通过应用业务用例,调整应用资源满足具体体验质量标准集。技术上,QoE是应用执行时间和网络交付时间的综合,而且这些在云端都可以实现多样化。处理云性能变量... 全文

云应用性能管理 APM 应用性能管理 云性能

ASP.NET中常用的26个优化性能方法

1. 数据库访问性能优化 数据库的连接和关闭... 全文

数据库 优化性能 ASP.NET 性能测试协商 性能测试

再谈性能测试

什么是性能测试?性能测试(在此主要指软件的性能测试)的定义各家各门派的定义很多,个人比较认同Wiki上面的解释:... 全文

性能测试协商 性能测试 测试

javascript加载和执行的性能优化

简介: 随着 Web2.0 技术的不断推广,越来越多的应用使用 JavaScript 技术在客户端进行处理,从而使 JavaScript 在浏览器中的性能成为开发者所面临的最重要的可用性问题。而这个问题又因 JavaScript 的阻塞特性变的复杂,也就是说当浏览器在执行 JavaScript 代码时,不能同时做其他任何事情。本文详细介绍了如何正确的加载和执行 JavaScript 代码,从而提高其在浏览器中的性能。无论当前 JavaScript 代码是内嵌还是在外链文件中,页面的下载和渲染都必须停下来等待脚本执行完成。JavaScript 执行过程耗时越久,浏览器等待响应用户输入的时间就越长。浏览器在下载和执行脚本时出现阻塞的原因在于,脚本可能会改变页面或 JavaScript 的命名空间,它们对后面页面内容造成影响。一个典型的例子就是在页面中使用document.write()。例如清单 1... 全文

javascript性能优化 性能优化

页面性能测试

上篇文章写了页面性能测试-QTP篇,我想大家都了解了怎么去实现页面性能测试了,那么我现在再来说一下如何用Ruby来实现,其实实现的思想都是一样的,唯一的区别就是适用的工具不一样而已。那么我为什么要是用Ruby再来实现一次,而不是用QTP呢?原因是ruby有着QTP所无法比拟的优点,这点让我下定决心来改变原先的QTP框架而使用Ruby。... 全文

性能测试协商 性能测试 QTP Ruby

WebLogic性能:速度不是一切

追求原始速度的过程,会使可读性强的代码变得晦涩难懂(通常是无用的——目前的优化编译器相当不错),从而导致以后维护困难;而且在很多情况下,整体方案中的优化性能指标无法吸引人们的兴趣。很多人只注重完成一次请求所需的时间——“这次交易仅用了20微秒就从储蓄帐户中取出500英镑,哇!”... 全文

WebLogic性能 软件测试 性能测试

性能测试数据分析经验

我以为福建移动BOSS系统做的一个小规模的性能测试为例,谈谈我在数据分析中的一些经验。测试用例,模式如下图。        一台Linux模拟Browser(简称browser)向主机SUN发 HTTP请求,SUN上启动Apache Web Server将请求交给FCGI程序。FCGI程序作为TE节点CC1(简称fcgi)的客户进程发起TE事务,经GT1名字服务向CC2 (简称svr_cc)发送一个分支,CC2 上服务嵌套经GT1名字服务向ACCTFZ(在HP上,简称svr_ac)发送一个分支。... 全文

性能测试协商 性能测试 BOSS系统

LinkBench

在数据库工程团队实习期间,我花费了上个暑假的时间分析了Facebook的数据库工作负载(workload)并帮助开发了一款称为LinkBench的数据库性能测试工具。这个周我们很荣幸的将LinkBench发布到了 GitHub上,并希望它能够成为每个需要进行性能测试和数据库调优工作的开发者手中的利器。 ... 全文

LinkBench 性能测试 数据库性能测试 性能测试工具

Linux服务器性能数据收集

Linux中的top,free等命令不能完全满足我们性能数据收集的要求,我们需要一个更加强大的工具来收集性能数据。经过考察和对比,发现Sysstat是一个非常强大的工具,因此下载了试了下,效果不错。Sysstat是一个工具集,包括sar、pidstat、iostat、mpstat、sadf、sadc。其中sar是其中最强大,也是最能符合我们测试要求的工具,同时pidstat也是非常有用的东东,因此本文结合性能测试重点介绍这两个工具。 Sysstat的安装从http://pagesperso-orange.fr/sebastien.godard/download.html下载最新版本,解压,安装... 全文

性能测试协商 性能测试 Linux 服务器

伟大骡子的一生和性能测试

经常上课时,大家就性能测试、压力测试和容量测试分不清楚,忽然想到用讲故事的方法来进行区别,可能难免有牵强之处,拿出来给大家加深一下印象。有一个农夫决定买一匹骡子,他认为这个骡子至少得能扛动3袋大米,他才会决定买这匹骡子(这相当于用户提出的性能需求)。结果他来到农贸集市上,试了好几头骡子,都不合适,最后终于有一头骡子能够比较轻松的扛动这3袋大米,而且还潇洒的走了几步(这相当于于性能测试通过)。... 全文

性能 压力测试测试 性能测试

2 3 4 5 6 7 8 9 10 11