qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

如何从一名测试员转型为管理人员

如果你是软件测试员或是高级测试员,有志转向管理发展,从技术方面,那么需要加强以下内容,至少要做到几点:
  1. 扎实的软件测试基本功,懂得测试计划的制作与编写(结合测试的项目,能以此来控制和确定测试所需人员,设备及时间)
  2.要熟悉BUG跟踪工具及软件测试流程.(如: QC, Bugzilla, Mantis等)
  3.要熟悉配置管理工具. (如: SVN,CVS, VSS等)
  4.要熟悉自动化工具.(例如:QTP, Robot, RFT, Selenium等,能结合录制完的脚本编写代码)
  5.要熟悉压力及性能测试工具.(例如: LoadRunner, webload, silkperformance等,能结合相关数据,分析出性能瓶颈)
  6.要熟悉或精通一门语言. (例如: C#,Java,C++)
  7.要熟悉数据库.(例如:Oracle, DB2, SQLServer, MySQL)
  8.要熟悉至少一种主流操作系统. (例如: HP Unix,IBM AIX, Sun Solaris, Red HatLinux, SuSE Linux,Windows)
  9. 必要的英文能力.
  10.语言表达能力强,表达问题清晰明了.
  11.沟通能力强,能和上级/开发经理很好的达成测试相关/BUG事宜.
  12.学习技术的能力要强,能快速上手一个新的技术,这是做软件行业必须的.
  13. 掌握管理技巧与团队建设,管理不是胡乱的管人.
  14.乐于与人交流.
  当然,现在的管理者,很多时候或者可以分为两类,一种是对业务和管理熟悉但不懂技术、另一种是对管理熟悉但不懂技术。
  在软件这一行业,我认为做为一个管理者,非常有必要懂得技术,以技术做为基础,推进开展部门工作,可以更高效快捷,也可以在部门中更令下属信服,不懂技术的管理者往往得不到下属发自内心的信服(特别是在人才济济的大公司或知名企业),以上列出的技术均为软件测试行业通用型的测试技术,在不同的企业,因业务性质和业务特征的不同,对技术的要求也存在一定差异(当然,如果具备较强的学习能力,这些“个性化需求”其实算不上什么)。
  懂技术的管理,才能走得更远!

posted @ 2014-08-25 10:08 顺其自然EVO 阅读(174) | 评论 (0)编辑 收藏

微软Modern.IE:网站兼容性测试利器

 面对浏览器生态不断加快的技术步伐,开发者很难确定自己的网页能否在浏览器上完美兼容。为了解决这一类问题,微软推出了一套免费的浏览器测试工具——旨在简化开发者的网页测试工作,提升网页优化效率,让开发者将精力放在创新上,让网页更加完美地呈现于全新的IE10浏览器。
  modern.IE
  用户只需通过输入URL地址即可并找出所有可能影响浏览体验的常见错误,并且把这些可能会导致兼容性问题或影响用户体验的常见错误罗列出来(推荐阅读:构建现代站点且同时支持旧版IE的20个提示)。而这些错误可体现出如下三类:与旧版IE浏览器产生的兼容性问题,在多设备、跨平台上是否能够正常运行,以及与Windows 8新特性的匹配状况。
  Web扫描工具
  1.解决关于兼容旧版IE的常见问题
  自从新版的IE9与IE10开始支持HTML5标准,而旧版本的IE却不支持,开发者通常需要为两者编写不同的代码。这使得测试不同版本的IE变得非常棘手——比如找出兼容模式下不支持的特性、让docmode告诉浏览器它支持Web标准、不小心使用了一个过时的jQuery框架。如果网站在最新版或预发行版中会引发兼容性问题,modern.IE也会提示您,使开发者可以更从容的在不同的版本间规划和解决问题。
  已知的兼容性问题(Known compatibility issues)
  兼容模式(Compatibility Mode)
  框架和库(Frameworks & libraries)
  网络标准文档模式(Web standards docmode)
  2.帮助网站在多种浏览器和设备上正常运行
  向导还包括了一系列最佳实践,让网页可以适用于日益增加的各种设备——不论是手机、台式机、平板电脑,甚至是大屏幕电视。实施特性检测、采用CSS前缀的最佳实践编码、搭建无插件网站、使用响应式网页设计,都可以减少跨浏览器、跨设备的测试时间,并提供更稳定的用户体验。
  CSS 前缀(CSS-prefixes)
  浏览器插件(Browser plug-ins)
  响应式网页设计(Responsive web design)
  浏览器检测(Browser detection)
 3.结合Windows 8中的一些新特性构建网站
  这包括触控浏览和“开始”屏幕网站磁贴。开发者可利用Windows的这些新功能,为用户提供更加个性化的浏览体验。
  触控浏览(Touch-browsing)
  “开始”屏幕网站磁贴(Start screen site tile)
  如何在多浏览器和跨平台设备上对站点进行全面的兼容性测试,modern.IE内置了著名的虚拟网页兼容性测试服务BrowserStack,这样无论开发人员使用何种设备和操作系统,都能用它来测试网页在不同浏览器下的运行状况。不过虚拟前端效果测试工具BrowserStack只提供3个月的免费使用权,只需在2014年1月31日之前激活即可。
  BrowserStack
  此外,modern.IE还提供Chrome与Firefox下的浏览器组件,还有新的Chrome和Firefox加载项和脱机虚拟机映像。
  modern.IE工具也考虑到同时使用Windows PC、Mac和Linux等多环境下的网页开发者,为他们统一提供了本地测试用的虚拟机VHD文件。
  例如Windows 8下的Hyper-V/VirtualPC、Mac下的VMWare Fusion/Parallels、Linux下的VirtualBox等一系列丰富的虚拟化工具选择,旨在让使用各种平台的Web开发者都能简单的参与到IE 10的兼容性测试中来。

posted @ 2014-08-25 10:03 顺其自然EVO 阅读(294) | 评论 (1)编辑 收藏

Windows下的Memcache安装与测试教程

 1、下载memcache for windows
  下载地址:http://splinedancer.com/memcached-win32/,推荐下载binaries版本,
  解压(本例中解压到e:memcached-1.2.4)。
  2、安装memcache,
  在命令行状态下输入: e:/memcached-1.2.4/memcached.exe -d install 。至此memcached已经安装成windows服务
  3、启动memcache,
  在命令行下输入: e:/memcached-1.2.4/memcached.exe -d start 以启动memcached服务。
  或者也可以选择在windows服务中启动
  到此,memcache的服务器端就准备完毕,接下来需要安装php的memcache扩展,
  php安装Memcached模块支持
  1、下载php_memcache.dll模块,
  你可以从http://downloads.php.net/pierre/找到对应的版本,
  php5.3对应php_memcache-2.2.6-5.3-vc9-x86.zip
  将php_memcache.dll放到php\ext目录下,
  2、修改php.ini来加入扩展,并并重启apache服务器
  加入extension=php_memcache.dll、重启apache服务器,
  然后查看一下phpinfo,如果有memcache,那么就说明安装成功!
  测试windows下的Memcached
  测试代码如下:
<?php
$mem = new Memcache;
$mem->connect("127.0.0.1", 11211);
$mem->set('key', 'Hello Memcached!', 0, 60);
$val = $mem->get('key');
echo $val;
?>
Example #1 memcache extension overview example
In this example, an object is being saved in the cache and then retrieved back. Object and other non-scalar types are serialized before saving, so it's impossible to store resources (i.e. connection identifiers and others) in the cache.
<?php
$memcache = new Memcache;
$memcache->connect('localhost', 11211) or die ("Could not connect");
$version = $memcache->getVersion();
echo "Server's version: ".$version."<br/>n";
$tmp_object = new stdClass;
$tmp_object->str_attr = 'test';
$tmp_object->int_attr = 123;
$memcache->set('key', $tmp_object, false, 10) or die ("Failed to save data at the server");
echo "Store data in the cache (data will expire in 10 seconds)<br/>n";
$get_result = $memcache->get('key');
echo "Data from the cache:<br/>n";
var_dump($get_result);
?>
Example #2 Using memcache session handler
<?php
$session_save_path = "tcp://$host:$port?persistent=1&weight=2&timeout=2&retry_interval=10,  ,tcp://$host:$port  ";
ini_set('session.save_handler', 'memcache');
ini_set('session.save_path', $session_save_path);
?>
memcached的基本设置:
  -p 监听的端口
  -l 连接的IP地址, 默认是本机
  -d start 启动memcached服务
  -d restart 重起memcached服务
  -d stop|shutdown 关闭正在运行的memcached服务
  -d install 安装memcached服务
  -d uninstall 卸载memcached服务
  -u 以的身份运行 (仅在以root运行的时候有效)
  -m 最大内存使用,单位MB。默认64MB
  -M 内存耗尽时返回错误,而不是删除项
  -c 最大同时连接数,默认是1024
  -f 块大小增长因子,默认是1.25
  -n 最小分配空间,key+value+flags默认是48
  -h 显示帮助
  接口介绍
  Memcache客户端包含两组接口,一组是面向过程的接口,一组是面向对象的接口,具体可以参考PHP手册 “LXXV. Memcache Functions” 这章。
  Memcache面向对象的常用接口包括:
  Memcache::connect — 打开一个到Memcache的连接
  Memcache::pconnect — 打开一个到Memcache的长连接
  Memcache::close — 关闭一个Memcache的连接
  Memcache::set — 保存数据到Memcache服务器上
  Memcache::get — 提取一个保存在Memcache服务器上的数据
  Memcache::replace — 替换一个已经存在Memcache服务器上的项目(功能类似Memcache::set)
  Memcache::delete — 从Memcache服务器上删除一个保存的项目
  Memcache::flush — 刷新所有Memcache服务器上保存的项目(类似于删除所有的保存的项目)
  Memcache::getStats — 获取当前Memcache服务器运行的状态
  Memcache::addServer — 分布式服务器添加一个服务器

posted @ 2014-08-25 09:55 顺其自然EVO 阅读(166) | 评论 (0)编辑 收藏

软件工程师获得足够尊重了吗?

软件工程师的日子当然是越来越好。”CNet 如是说。招聘网站 Glassdoor 对此表示同意:软件工程师的平均工资是85000 美元,旧金山地区更是达到六位数 (我个人觉得还有点低了)。对软件工程人才需求的暴涨是众所周知的。那么,为什么还有人会认为软件工程师是被践踏、被鄙视,被剥夺权利的一个群体?
  ……其实,他们差不多说准了一部分。
  一个名为麦可·O·彻奇(Michael O. Church)的作家就是其中一员。他对比了同一个申请者申请“高级软件工程师”与“数据科学副总管”(一个管理职位)两个岗位的不同经历。为申请软件工程师,他需要通过五层严苛的技术考核,其中任意一层的面试官都有一票否决权。而申请管理职位则完全不同,面试的问题简单多了,他基本上就是在聊天,最后公司往往会提供不错的职位,甚至还有一笔可观的安家费。彻奇认为这种差异的出现就是因为软件工程师的社会地位比管理人员低,而即使是管理职位的申请人,只要他们能证明自己的实力,也和正式的管理人员有相同的地位:
  [作为管理人才],总裁跟比尔(注:文中的申请者)进行了平等的对话。谈话没有居高临下的家长式的威严,也没有说“你的职业生涯在这里起飞”之类的大话。实际上,这种对话可不是一个软件工程师和一个百人规模的高科技公司的首席执行官之间能听到的。
  那么既然这是事实,我们又怎么把这个问题推到席面上?彻奇一直有个不好的习惯,那就是把一些小问题夸张化戏剧化,最后让它偏离正确的方向,所以他的这篇博文被程序员社区疯狂转载,不过他似乎就是喜欢这种感觉。
  事实上,一些非常成功的企业,特别是 Facebook 和谷歌,都是以工程师文化闻名全球的,他们中间的非常、非常多的工程师都有可能晋升成为高管从而获得了更大的成功。此外,我已经反复不停地说过,一本正经的技术考核是最没水平的工程师评价系统,如果面试官已经给面试者设置了西游记般的重重险阻(并且这一点意义也没有),那么要求双方再保持平等的地位绝对是不可能了。
  造成这些的原因不止是面试。工程师往往被视为四体不勤的头脑苦力,他们的语言只有电脑才懂,思维也刻板得像个电脑,不像商务人士有资格做出最重要的决策。分析师、产品经理、工商管理硕士才是生意的运转者,他们赏给工程师物质,但绝不会把他们的意见当回事,尤其是在管理方面的意见。
  而实际上,任何称职的工程师都会告诉你,为了完成本职工作,他们每天必须不断地进行业务决策,只不过是在微观而不是宏观层面——这个数据库字段究竟要多长?应该采用什么数据类型?如何进行校验?如何处理所有的边缘情况?这些其实都是商业决定,是工程师决定的商业行为,也是产品经理一辈子都做不了的决定,他们有时候甚至根本不知道什么是技术上可以实现,什么是不能实现的。
  诚然,优秀的管理者要在无休止的信息不对等情况下做出好的判断,既要满足上司的要求,还要保持下属的愉悦和紧张感,给客户超出预期的结果。这是个极其困难的工作。你可能会说(我也可能会说),优秀管理者和优秀工程师一样稀缺,这就是他们的价值。
  但在这里我不是在讨论两者的价值比较,而是软件工程师这个企业底层群体在重要决策中被忽视的现实。我们讨论的是工程师被越来越多的人贴上古板、自闭、天真、神经大条、见不了大世面的标签。这种想法在“技术”和“商业”联系越来越紧密的当下,无疑是不可想象的。
  同时,那些完全不懂技术的管理人员势必将给公司运营带来负面效应。那些从来没写过代码或者焊接过二极管的人不会真正明白工程师的世界,他们只能盲目相信工程师的选择。而矛盾的是,这种不对等导致了更少的尊重,最后导致整个公司气氛难以调和。
  我的结论?彻奇是对的,但仅限一些企业,比如那些不了解或不尊重工程师的企业。如果企业的业务和技术完全无关,那么看低工程师还算是有一定的理由, 不过当下这种企业几乎是屈指可数了。作为软件工程师,如果你发现你在供职单位受到的待遇不如商科背景的雇员,甚至被当做码农和苦力,那么你一定得好好考虑一下自己的未来了。

posted @ 2014-08-25 09:50 顺其自然EVO 阅读(162) | 评论 (0)编辑 收藏

Linux生成随机密码教程

通常情况下大家对于生成密码都好困惑,一来复杂程度不够会不安全,复杂程度够了又不能手动随便敲击键盘打出一同字符(但通常情况下这些字符是有规律的),使用 1password 或者 keepass 这种软件生成也可以,不过貌似1password 要收费,既然这样我们就玩一下好玩的用 linux 来生成随机密码玩玩吧;
  Linux操作系统的一大优点是对于同样一件事情,你可以使用高达数百种方法来实现它。例如,你可以通过数十种方法来生成随机密码。本文将介绍生成随机密码的十种方法。
  1、使用SHA算法来加密日期,并输出结果的前32个字符:
  2、使用内嵌的/dev/urandom,并过滤掉那些日常不怎么使用的字符。这里也只输出结果的前32个字符:
  3、用openssl的随机函数
  4、这种方法类似于之前的urandom,但它是反向工作
  5、使用string命令,它从一个文件中输出可打印的字符串
  6、这是使用urandom的一个更简单的版本

  7、使用非常有用的dd命令
  8、甚至可以生成一个只用左手便可以输入的密码
  9、如果每次都使用上述某种方法,那更好的办法是将它保存为函数。如果这样做了,那么在首次运行命令之后,你便可以在任何时间只使用randpw就可以生成随机密码。或许你可以把它保存到你的~/.bashrc文件里面
  10、最后这种生成随机密码的方法是最简单的。它同样也可以在安装了Cygwin的Windows下面运行。在Mac OS X下也可以运行。我敢肯定会有人抱怨这种方法生成的密码没有其它方法来的随机。但实际上如果你使用它生成的全部字符串作为密码,那这个密码就足够随机了。

posted @ 2014-08-22 09:53 顺其自然EVO 阅读(262) | 评论 (0)编辑 收藏

RAC数据库启用归档和闪回的步骤

 1、RAC数据库调整为归档模式步骤:
SQL> alter system set cluster_database=false scope=spfile sid='orcl1';
SQL> alter system set db_recovery_file_dest='+ORAFLASH' scope=spfile;
SQL> alter system set db_recovery_file_dest_size=20g scope=spfile;
$ srvctl stop database -d orcl
$ sqlplus / as sysdba;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter system set cluster_database=true scope=spfile sid='orcl1';
SQL> shutdown immediate;
$ srvctl start database -d orcl
SQL> select name,log_mode,flashback_on from v$database;
  2、RAC数据库启动闪回特性步骤:
  确认数据已经运行在归档模式中:
SQL> archive log list;
SQL> alter system set cluster_database=false scope=spfile sid='orcl1';
SQL> alter system set db_recovery_file_dest='+ORAFLASH' scope=spfile;
SQL> alter system set db_recovery_file_dest_size=20g scope=spfile;
$ srvctl stop database -d orcl
SQL> startup mount;
SQL> alter database flashback on;
SQL> alter system set cluster_database=true scope=spfile sid='orcl1';
SQL> shutdown immediate;
$ srvctl start database -d orcl
  注意:可以根据需要为特定的表空间打开或关闭闪回:
  SQL> alter tablespace users flashback on;
  SQL> alter tablespace users flashback off;
  SQL> select name,log_mode,flashback_on from v$database;

posted @ 2014-08-22 09:52 顺其自然EVO 阅读(179) | 评论 (0)编辑 收藏

我们需要什么样的需求管理工具?

这篇博文的标题是一个疑问句。在回答这个问题之前,首先应该想到的是:提出这个问题,实际上已经先认定了需求管理工具是必要的。那么,需求管理工具是否真的必要呢?
  这里的“需求”不是个抽象概念,它指的是需求分析文档、需求规格说明文档这样的需求分析成果;需求管理就是对这些成果(包括中间成果)的管理。从这个角度来看,需求管理工具是必要的,至少在绝大多数情况下是这样。根据经验,我至少能够列出以下两个理由:
  1、在绝大多数情况下,需求是复杂的。
  2、在绝大多数情况下,需求是变化的。
  需求分析过程往往是这样的:从用户关于系统的一些模糊的、顶层的概念和想法出发,不断地进行明确和分解,形成数量众多的需求条目,直到最终成为可以指导开发的用例。随着这一过程的进行,当程序员因为需求越来越清晰而备受鼓舞时,不幸的项目经理却很可能陷入苦恼中:这么多条需求,谁知道是否有遗漏呢?谁知道这些条目之间是否有很紧密的关联呢?如果需求条目比较少,或许项目经理还能够在脑子里把这些问题理清楚;但是如果条目很多,谁又能保证不出错呢?
  需求的变化有多种来源:有可能用户的想法发生了改变;有可能用户的想法并没有变,但一开始他没有说清楚,或者我们的理解有误;实际上,需求分解本身就意味着我们对需求的认识在不断地深入和细化。
  所以我们可以借助工具管理好需求,以结构化的形式(例如树形图、表格等)来组织需求条目,让项目经理能够比较方便地查看、追踪、回溯需求分解,理解需求条目之间的关系。
  所以我们可以借助工具管理好需求,不但要能够很方便地进行“增删查改”,最好还能像代码版本控制那样,对需求分析的成果也能进行版本控制。
  事实上,在行为驱动开发(Behavior Driven Development, BDD)或者验收测试驱动开发(Acceptance Test Driven Development, ATDD)中,需求与验收测试代码最终合二为一,即所谓specification by example。所以对需求进行管理,就像对代码进行管理一样,是非常自然的事情。
  那么,什么样的需求应该被工具管理起来呢?
  我们可以把需求分为三类:
  1、功能需求:即系统应当提供哪些功能,例如“支持在用户登录时进行用户身份认证”;
  2、性能需求:即性能方面的指标,例如“当用户登录请求并发数不大于200时,身份认证处理时延不大于3秒”;
  3、特性:对某项功能实现的方式、界面、操作步骤、外观、接口等进行规定的需求,例如“服务器与客户端之间的消息传输采用HTTP协议”。
  性能需求会对系统技术路线的选择、架构设计等产生直接的影响,但是通常不易被分解为更细的条目;特性往往会体现在某项功能的实现方式或呈现形式上,通常我们都是把功能需求进行分解,并且在分解时注意把相应的特性包括进去。因此,实际上需求管理工具首先应该管理的是功能需求。
  所以,为了较好地支持BDD或者ATDD,我觉得需求管理工具至少应该具有以下功能:
  一、能够以树形图或表格的方式浏览所有需求条目。以下以树形图为例进行说明:
  1、树形图具有唯一的根节点,就是“系统功能需求”,根节点以下可以有任意多层分支节点;
  2、每个节点是一个需求条目,具有编号、名称、说明3项内容;
  3、采用多级编号,编号能够体现需求条目之间的逻辑关系;
  4、如果系统包括多个子系统(例如多个软件),那么第1层分支节点是系统功能,从第2层分支节点开始是子系统功能,即第1层分支节点只把系统功能需求进行分解,不按子系统分解;从第2层分支节点开始,按子系统进行分解,第2层分支节点应注明是“客户端xxx功能”还是“服务器xxx功能”;
  5、最末端的分支节点(即叶子节点)采用BDD验收测试代码的feature文件的形式(例如cucumber的feature文件);
  6、每个节点可以展开(显示子节点)和收拢(不显示子节点)。
树形图如下图所示:
系统功能需求--+--1.用户登录--+--CLIT.1.1客户端登录界面
+              +
+              +--SERV.1.1服务器身份认证
+              +
+              +--SERV.1.2服务器维护用户登录会话状态
+
+--2.XXXX--+--CLIT.2.1XXXX--+--CLIT2.1.1XXXX
+          +                +
+          +--CLIT.2.2XXXX  +--CLIT2.1.2XXXX
+          +
+          +--SERV.2.1XXXX
+          +
+          +--SERV.2.2XXXX--+--SERV2.2.1XXXX--+--SERV2.2.1.1XXXX
+                           +                 +
+                           +--SERV2.2.2XXXX  +--SERV2.2.1.2XXXX
+                           +
+                           +--SERV2.2.3XXXX
+--3.XXXX
  二、对每个节点可以进行以下操作:
  1、通常的操作有:编辑、添加下级分支节点、添加叶子节点、改变上级节点(从而可以改变节点之间的逻辑关系);
  2、如果已经是叶子节点,则不能再添加下级。
  三、能够把所有叶子节点导出为feature文件,这些feature文件可以直接在测试代码中使用。
  1、每个叶子节点是一个单独的feature文件;
  2、feature文件分目录存放,目录结构与树形图的分层结构一致。
  四、能够把所有节点导出为一个文本文件,文本文件的章节结构与树形图的分层结构一致。

posted @ 2014-08-22 09:51 顺其自然EVO 阅读(208) | 评论 (0)编辑 收藏

Java类文件的基本结构

为旅行而生
  Java类文件(.class文件)是一个为已编译Java程序仔细定义的格式。Java源代码被编译成能够被任何JVM加载和执行的类文件。在被JVM加载之前,类文件可能是由网络传输而来。
  类文件是独立于底层平台的,所以适用于更多的地方。它们由简洁的JVM字节码组成,这样就能轻装上阵。类文件常常被压缩,以极快的速度通过网络,到达世界各地的JVM。
  类文件里有什么?
  Java类文件包含JVM需要知道的关于一个Java类或接口的一切。按照它们的出现次序,主要的部分有:魔法数(magic),版本号(version),常量池(constant pool),访问标示符区(access flags),当前类区(this class),超类区(super class),父接口区(interfaces),字段区(fields),方法列表区(methods),属性区(attributes)。
  保存在类文件中的信息经常在长度上有变化,所以信息的实际长度在被加载之前不能被预测。例如,在方法区里的方法数目,类与类之间是不相同的,这取决于源代码中定义的方法个数。类文件中,这些信息的实际大小或长度,被安排在信息内容之前。这样,当类文件被JVM加载时,可变信息的长度首先被读取。一旦JVM知道信息的大小,它就能正确的读取实际的信息内容。
  类文件中,不同的相邻信息之间通常没有空白或填充字符;一切都以字节(byte)边界对齐。这使得类文件很小,适合网络传输。
  为了让JVM在加载类文件时,知道需要什么信息以及从哪里可以取得所需信息,类文件的各个组成部分的次序是严格定义的。例如,每个JVM都知道类文件的前8个字节由魔法数和版本号组成,常量池从第9个字节开始,访问标示符区紧跟在常量池后面。但是,因为常量池的长度是可变的,在读取完常量池之前,JVM是不知道访问标示符区具体从什么地方开始。一旦读取完常量池,JVM就知道接下来的2个字节就是访问标示符区。
  魔法数(Magic)和版本号(Version)
  每个类文件的开始4个字节都是0xCAFEBABE。这个神奇的数字让Java类文件更容易识别,因为类文件以外的文件几乎不可能也以这四个相同的字节开头。之所以称之为魔法数,是因为它可以被文件格式设计者们从帽子里拉出来(??)。对它仅有的要求是,不能被现实已有的文件格式占用。根据最初Java团队主要成员之一的Patrick Naughton所说,远在“Java”被当作Java语言的名称之前,这个神奇的数字就已经被选好了。我们当时在寻找一个有趣,独特并且很容易记住的数字。0xCAFEBABE作为漂亮的Peet’s Coffee的咖啡师的代称,能预示未来Java语言的名字,这完全是一个巧合。
  类文件接下来的4个字节包含了大版本号(major version)和小版本号(minor version)。这些数字标识了特定类文件使用的类文件格式,让JVM可以验证类文件是否可以被载入。每个JVM都有一个它能载入的最大版本号,拒绝加载大于最大版本号的类文件。
  常量池(Constant Pool)
  类文件在常量池中保存与类或接口关联的常量。常量池中能看到的部分常量是字符串字面值(literal strings),final变量的值(final variable values),类名,接口名,变量名和变量类型,方法名和方法签名(method names and signatures)。方法签名由方法返回值类型(return type)和一组参数类型(argument types)组成。
  常量池被组织成一个元素长度可变的数组。每个常量占据数组中的一个元素。在整个类文件中,常量通过指示它们在数组中位置的整型索引来引用。第一个常量的索引值是1,第二个是2,以此类推。常量池数组的元素个数写在常量池的前面,所以在加载类文件时,JVM知道它需要加载多少常量。
  常量池中每个元素以指明自己类型的单字节标签(tag)开始。一旦JVM看到这个标签,就能知道接下来会遇到什么类型的常量。例如,如果看到一个表示字符串的标签,JVM会认为接下来2个字节就是字符串的长度,然后就是“长度”个字节组成的字符串。
  在本文剩下的部分,我有时会用constant_pool[n]表示常量池数组的第n个元素。从常量池组织的像个数组来说,这是有道理的;但是请记住,这些元素具有不同的大小和类型,并且第一个元素的索引是1。
  访问标识符区(Access Flags)
  常量池之后的2个字节就是访问标示符,它表明该文件定义的是类还是接口;该类或接口是公开的(public)还是抽象的(abstract);如果是类,该类是不是final的。
  当前类区(This class)
  接下来2个字节是当前类区,它是常量池数组的索引。被当前类引用的常量constant_pool[this_class],包含两部分:单字节标签(tag)和双字节名称索引(name index)。标签等于CONSTANT_Class,一个表示本元素中包含类或接口信息的值。constant_pool[name_index]是一个包含类或接口名的字符串常量。
  当前类部分稍稍揭示了常量池是怎么被使用的。当前类区本身只是一个常量池的索引。当JVM查找constant_pool[this_class]时,它找到一个用标签表明自己是一个CONSTANT_Class得元素。JVM知道CONSTANT_Class元素在标签(tag)之后,总是有一个叫名称索引(name index)的常量池双字节索引。然后它查找constant_pool[name_index],得到包含类或接口名的字符串。
.超类区(Super class)
  当前类区之后是超类区,也是2个字节的常量池索引。constant_pool[super_class]是CONSTANT_Class元素,它指向当前类所直接继承的超类名。
  接口区(Interfaces)
  接口区开头的2个字节,表示文件所定义的类(或接口)实现的接口数目。紧接着是一个数组,它包含了类所实现的每一个接口在常量池中的索引。
  每个接口都是常量池中的CONSTANT_Class元素,它指向接口名。
  字段区(Fields)
  字段部分,以表示该类或接口包含的字段数的2个字节开始。字段是一个实例变量,或者是类或接口的类变量。接下来是一个以可变长结构为元素的数组,一个结构一个字段。每个结构都包含一个字段的相关信息,如字段名,字段类型,如果是final变量,还包括字段值。部分信息在结构当中,另一部分在常量池中由结构所指向的位置。
  这部分仅有的字段,都是由定义在该类文件中的类或接口声明的变量;继承自超类或接口的字段不在此列。
  方法区(Methods)
  方法部分,以表示类或接口中方法数目的2字节开始。这个数目,只包含当前类显式定义的方法,不包括继承自超类的方法。数目之后是方法本身。
  表示每个方法的结构包含方法相关的几条信息,包括方法描述符(method descriptor,包括返回值类型和参数列表),方法本地变量需要的栈字(stack words)数,方法操作数栈(operand stack)需要的最大栈字数,方法捕获的异常表,字节码序列和行号表。
  属性区(Attributes)
  排在最后的是属性区,它提供定义在类文件中的特定类或接口的一般信息。属性区以2字节的属性数目开始,然后是属性本身。比如一个表示源码属性的属性:它表示当前类被编译而来的源文件名。JVM会悄悄地忽略任何它们识别不了的属性。

posted @ 2014-08-22 09:51 顺其自然EVO 阅读(201) | 评论 (0)编辑 收藏

Junit指定运行的测试方法

public static Test suite()
{
//以下是用来增加单个测试用例,测试用例类的名称为RunTimeTest
TestSuite suite = new TestSuite("ALL TEST");     //通过Junit自带的TestSuite基类创建一个TestSuite类型的对象suite
//以下这句将运行RunTimeTest中被指定的方法,如testreValue
suite.addTest(new RunTimeTest("testreValue")); //将一个测试用例类中的特定方法添加到suite中,以便在main函数中运行
//以下这句将运行RunTimeTest中的所有测试方法
//suite.addTestSuite(RunTimeTest.class);            //将整个测试用例类中的所有方法都添加到suite中,以便在main函数中运行
//以下这句讲运行RunTimeTest.suite()中规定的一组方法
//suite.addTest(RunTimeTest.suite());                //先将一个测试用例类中指定的方法添加到suite中,然后将这一个suite添加到suite中,以便运
//行这一组方法
return suite;
}
public static void main(String[] args)
{
//以下三种方式均可以,具体情况可运行以下,看一下结果
// junit.textui.TestRunner.run(TestUnit.class);//如果没有制定特定的suite,则自动映射为执行用例类中所有的testXXX方法
// junit.swingui.TestRunner.run(Test.class);
// junit.awtui.TestRunner.run(Test.class);
// junit.swingui.TestRunner.run(TestUnit.class);
junit.textui.TestRunner.run(suite());               //运行测试用例类中添加到suite中的方法
}
}

posted @ 2014-08-22 09:43 顺其自然EVO 阅读(375) | 评论 (0)编辑 收藏

码农的性能测试

 1.如何理解TPS
  性能指标的一个重要因素。TPS(Transaction Per Second,每秒事物数),单位时间内完成的事物的数量。TPS的计算一般是通过的事物除以时间。
  TPS是跟测试脚本中事物(Transaction)相关联的。
  在性能测试工具中,吞吐量也被称之为TPS(Transaction Per Second,每秒事物数)。吞吐量直接体现系统性能的承载能力,是指单位时间内处理的客户请求的数量。其计量单位可以根据需求不同而不同,比如请求数/秒,页面数/秒,业务数/小时(可以说下我们采集项目中吞吐量可以用 解析卡数/秒)。
  对于交互式应用,用户直接的体验就是“响应时间”,通过“并发用户数”和“响应时间”可以确定系统的性能规划;但对于非交互式应用,用“吞吐量”来描述用户对系统的性能期望可能更加合理。
  吞吐量作为性能测试的主要关键指标。吞吐量和并发用户数之前存在着一定的联系。在没有性能瓶颈的时候,吞吐量随着虚拟用户数的增加而增加(计算公式为 吞吐量 = (VU个数 * 每个VU发出请求数) / 单位时间)。如果性能遇到瓶颈,吞吐量与VU数理之间就不再符合这个关系。
  2.如何理解线程调用
  线程(thread)是”进程”中某个单一顺序的控制流。也被称为轻量进程。
  线程的好处:
  1 创建一个新线程花费的时间少。
  2.(JAVA中线程具有新的,可运行,运行,等待/阻塞/休眠,死亡等几种状态。)在未阻塞情况下,两个线程(在同一进程中的)的切换时间少。在阻塞情况下,线程间切换将产生上下文切换。
  3.由于同一个进程内的线程共享内存和文件,所以线程之间互相通信不必调用内核。
  4 线程能独立执行,能充分利用和发挥处理机与外围设备并行工作的能力。
  使用线程可以把占据长时间的程序中的任务放到后台去处理
  ps:JAVA中可以通过jstack或者jprofiler dump出线程所执行的堆栈信息。
  3.如何理解响应时间
  响应时间反映完成某个业务所需要的时间。
  在性能测试中是通过测试工具的事物函数来完成响应时间的统计。事物函数会记录开始事物和结束事物的时间差,使用Transaction Response Time这个词来说明。
  响应时间主要包括网络时间,服务器处理时间,网络延迟
  对于交互式应用,用户直接的体验就是“响应时间”,通过“并发用户数”和“响应时间”可以确定系统的性能规划;
  对于交互式应用,响应时间出现拐点系统就可能出现瓶颈
  4.如何理解性能建模(可分类回答)
  这个不会,之前找到一个资料,分享一下吧 http://www.docin.com/p-452373613.html
  5.如何理解响应时间,TPS曲线和用户之间的关系
  随着用户数量的增加,在未出现瓶颈前响应时间保持稳定,TPS值和并发用户数成线性关系,出现瓶颈后响应时间变长,TPS基本保持不变或开始下降。
  6.在LoadRunner中为何要设置思考时间和pacing?
  1)Think time,思考时间。可以通过设置思考时间,来模拟真实用户在操作过程中的等待时间。从定义上来看,think time是在iteration内部的某个action中各个步骤的间隔时间。
  2)Pacing,步调。可以通过设置两次迭代(iteration)之间的间隔时间,来调整各个action之间的步调(或者称之为节奏)。
  3)pacing和think time都是可以模拟现实世界中的停顿。对于复杂场景,这个停顿要靠pacing来完成。不过,pacing怎么设置才最合适,是需要研究用户行为才能定的。
 操作系统
  1.如何判断CPU、内存、磁盘的瓶颈?
  CPU瓶颈:
  1) 查看CPU利用率。建议CPU指标如下
  a) User Time:65%~70%
  b) System Time:30%~35%
  c) Idle:0%~5%
  如果us,sy高于这个指标可以判断CPU有瓶颈
  使用top查看
  查看运行队列
  每个CPU都会维持一个运行队列,理想情况下,调度器会不断让队列中的进程运行。进程不是处在sleep状态就是run able状态。如果CPU过载,就会出现调度器跟不上系统的要求,导致可运行的进程会填满队列。队列愈大,程序执行时间就愈长。“load”用来表示运行队列,用top 命令我们可以看到CPU一分钟,5分钟和15分钟内的运行队列的大小。这个值越大表明系统负荷越大。超过 1.00,那么说明CPU已经超出负荷,交通严重的拥堵。
  使用top或者uptime查看
  查看上下文切换
  每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程,Linux采用抢占式调度。即为每个线程分配一定的执行时间,当到达执行时间,线程中有IO阻塞或高优先级线程要执行时,Linux将切换执行的线程,在切换时要存储目前线程的执行状态,并恢复要执行的线程状态,这个过程称之为上下文切换。对于java应用,典型的是在进行文件IO操作,网络IO操作,锁等待或线程sleep时,当前线程会进入阻塞或者休眠状态,从而触发上下文切换,上下文切换过多会造成内核占用过多的CPU使用,使得应用的响应速度下降。
  使用vmstat查看cs
  结论:
  检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.
  确定CPU 利用率中user/system比例维持在70/30
  当CPU 开销更多的时间在system mode,那就说明已经超负荷并且应该尝试重新调度优先级
  当I/O 处理得到增长,CPU 范畴的应用处理将受到影响
  ps:对于JAVA应用,CPU瓶颈可以通过jprofiler监控分析
  内存瓶颈:
  1.查看利用率(free)
  used:已使用多大。
  free:可用有多少。
  Shared:多个进程共享的内存总额。
  Buffers/cached:磁盘缓存的大小。
  2.查看页交换,swap交换(po,pi,so,si),磁盘IO(vmstat)
  si: 每秒从交换区写到内存的大小
  so: 每秒写入交换区的内存大小
  page in :分页(Page)从磁盘重新回到内存的过程被称作Page-In
  page out : 分页(Page)写入磁盘的过程被称作Page-Out
  另外在进行页交换的时候,会产生磁盘IO,还需注意bi,bo
  Bo 磁盘块页面从内存到文件或交换设备的总额
  Bi 磁盘块页面从文件或交换设备到内存的总额
  3.page fault(pidstat -r,sar -B )
  minflt/s: 每秒次缺页错误次数(minor page faults),次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page fault次数
  majflt/s: 每秒主缺页错误次数(major page faults),当虚拟内存地址映射成物理内存地址时,相应的page在swap中,这样的page fault为major page fault,一般在内存使用紧张时产生
  其中sar -B中fault/s表示每秒钟minflt,majflt的和。
  结论:
  监控虚拟内存性能由以下几个部分组成:
  1.当系统中出现较少的页错误,获得最好的响应时间,是因为memory caches(译注:内存高速缓存)比disk caches更快(译注:磁盘高速缓存).
  2.较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swap device和disk.
  3.如果系统不断报告,swap device总是繁忙中,那就意味着内存已经不足,需要升级了.
  zee:
  如果用做缓冲区(buff)和快速缓存(Cache)的物理内存不断地增加,而空闲的物理内存(free)不断地减少,证明系统中运行的进程正在不断地消耗物理内存。
  已经使用的虚拟内存(swpd)不断增加,而且存在着大量的页面交换(si和so),证明物理内存已经不能满足系统需求,系统必须把物理内存的页面交换到磁盘中去。
  由此可以得到这样的结论:该主机上的物理内存已经不能满足系统运行的需要,内存已成为该系统性能的一个瓶颈。
  ps:对于java程序,内存瓶颈可以通过heap dump后使用mat分析
  磁盘瓶颈:
  iostat查看IO信息。如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。
  另外还需要注意iowait这个值,iowait 值高就意味着磁盘缓慢或负载过大。还有不要信任svctm这个字段。
  监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.
  ps:磁盘瓶颈可以通过pidstat -d 定位程序
  2.如何理解CPU、内存、磁盘的关系?
  这些子系统之间关系是彼此联系,相互彼此依赖的
  1.对于进程来说,数据是存放在内存中的,进程的运行需要使用CPU,进程读写数据需要跟磁盘打交道。
  2.当内存不足时需要跟磁盘进行页(page)交换,swap交换,从而产生磁盘IO。po,so释放物理内存,pi,si增加物理内存使用。交换分页的过程需要占用cpu时间。 (内存占用过高)
  3.当磁盘IO负载过高时,需要监控swap和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈。磁盘的相当慢的,当iowait 增长,表示CPU花费大量的时间在等待磁盘IO,此时CPU Bound的应用处理将受到影响(磁盘IO过高)
  3.如何理解paging in / paging out ?
  在Linux内存管理中,主要是通过“调页Paging”和“交换Swapping”来完成上述的内存调度。调页算法是将内存中最近不常使用的页面换到磁盘上,把活动页面保留在内存中供进程使用。交换技术是将整个进程,而不是部分页面,全部交换到磁盘上。
  分页(Page)写入磁盘的过程被称作Page-Out,分页(Page)从磁盘重新回到内存的过程被称作Page-In。当内核需要一个分页时,但发现此分页不在物理内存中(因为已经被Page-Out了),此时就发生了分页错误(Page Fault)。
  当系统内核发现可运行内存变少时,就会通过Page-Out来释放一部分物理内存。经管Page-Out不是经常发生,但是如果Page-out频繁不断的发生,直到当内核管理分页的时间超过运行程式的时间时,系统效能会急剧下降。这时的系统已经运行非常慢或进入暂停状态,这种状态亦被称作thrashing(颠簸)。
  可以通过vmstat -s 查看 paged in/out 数量
  4.如何监控操作系统的资源?(可用一个操作系统做例子)
  (把简历上部分内容直接贴出来了,懒的整理了)
  CPU监控:top(利用率), uptime(运行队列数), vmstat(上下文切换数), jprofile(方法占用cpu时间百分比)
  内存监控:top, free(利用率), vmstat(page和swap交换), pidstat -r和sar -B(page fault), jmap -heap(堆dump), mat和jprofiler(查看对象)
  磁盘监控:iostat(%util), top(iowait%), pidstat -d
  网络监控:netstat(连接数), nethogs(流量), wireshark和tcpdump(抓包)
  JVM监控:jstat(gc), jmap(堆dump), jstack(线程dump), jprofiler和visualvm(剖析工具)
  nmon(长时间全局收集数据)
  5.如何理解内存管理和线程调度?(可用一个操作系统做例子)
  不会
  6.如何理解上下文切换(context switch)?(可用一个操作系统做例子)
  每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程,Linux采用抢占式调度。即为每个线程分配一定的执行时间,当到达执行时间,线程中有IO阻塞或高优先级线程要执行时,Linux将切换执行的线程,在切换时要存储目前线程的执行状态,并恢复要执行的线程状态,这个过程称之为上下文切换。对于java应用,典型的是在进行文件IO操作,网络IO操作,锁等待或线程sleep时,当前线程会进入阻塞或者休眠状态,从而触发上下文切换,上下文切换过多会造成内核占用过多的CPU使用,使得应用的响应速度下降。
  vmstat其中cs那一列
  7.如何理解磁盘IO?(可用一个操作系统做例子)
  磁盘IO速度是非常慢的,linux内核就是要尽量降低IO
  内存不足时会进行页交换,产生磁盘IO
  CPU Bound类型应用,当磁盘IO过多,iowait过大时会影响性能。
 操作系统
  1.如何判断CPU、内存、磁盘的瓶颈?
  CPU瓶颈:
  1) 查看CPU利用率。建议CPU指标如下
  a) User Time:65%~70%
  b) System Time:30%~35%
  c) Idle:0%~5%
  如果us,sy高于这个指标可以判断CPU有瓶颈
  使用top查看
  查看运行队列
  每个CPU都会维持一个运行队列,理想情况下,调度器会不断让队列中的进程运行。进程不是处在sleep状态就是run able状态。如果CPU过载,就会出现调度器跟不上系统的要求,导致可运行的进程会填满队列。队列愈大,程序执行时间就愈长。“load”用来表示运行队列,用top 命令我们可以看到CPU一分钟,5分钟和15分钟内的运行队列的大小。这个值越大表明系统负荷越大。超过 1.00,那么说明CPU已经超出负荷,交通严重的拥堵。
  使用top或者uptime查看
  查看上下文切换
  每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程,Linux采用抢占式调度。即为每个线程分配一定的执行时间,当到达执行时间,线程中有IO阻塞或高优先级线程要执行时,Linux将切换执行的线程,在切换时要存储目前线程的执行状态,并恢复要执行的线程状态,这个过程称之为上下文切换。对于java应用,典型的是在进行文件IO操作,网络IO操作,锁等待或线程sleep时,当前线程会进入阻塞或者休眠状态,从而触发上下文切换,上下文切换过多会造成内核占用过多的CPU使用,使得应用的响应速度下降。
  使用vmstat查看cs
  结论:
  检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.
  确定CPU 利用率中user/system比例维持在70/30
  当CPU 开销更多的时间在system mode,那就说明已经超负荷并且应该尝试重新调度优先级
  当I/O 处理得到增长,CPU 范畴的应用处理将受到影响
  ps:对于JAVA应用,CPU瓶颈可以通过jprofiler监控分析
  内存瓶颈:
  1.查看利用率(free)
  used:已使用多大。
  free:可用有多少。
  Shared:多个进程共享的内存总额。
  Buffers/cached:磁盘缓存的大小。
  2.查看页交换,swap交换(po,pi,so,si),磁盘IO(vmstat)
  si: 每秒从交换区写到内存的大小
  so: 每秒写入交换区的内存大小
  page in :分页(Page)从磁盘重新回到内存的过程被称作Page-In
  page out : 分页(Page)写入磁盘的过程被称作Page-Out
  另外在进行页交换的时候,会产生磁盘IO,还需注意bi,bo
  Bo 磁盘块页面从内存到文件或交换设备的总额
  Bi 磁盘块页面从文件或交换设备到内存的总额
  3.page fault(pidstat -r,sar -B )
  minflt/s: 每秒次缺页错误次数(minor page faults),次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page fault次数
  majflt/s: 每秒主缺页错误次数(major page faults),当虚拟内存地址映射成物理内存地址时,相应的page在swap中,这样的page fault为major page fault,一般在内存使用紧张时产生
  其中sar -B中fault/s表示每秒钟minflt,majflt的和。
  结论:
  监控虚拟内存性能由以下几个部分组成:
  1.当系统中出现较少的页错误,获得最好的响应时间,是因为memory caches(译注:内存高速缓存)比disk caches更快(译注:磁盘高速缓存).
  2.较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swap device和disk.
  3.如果系统不断报告,swap device总是繁忙中,那就意味着内存已经不足,需要升级了.
  zee:
  如果用做缓冲区(buff)和快速缓存(Cache)的物理内存不断地增加,而空闲的物理内存(free)不断地减少,证明系统中运行的进程正在不断地消耗物理内存。
  已经使用的虚拟内存(swpd)不断增加,而且存在着大量的页面交换(si和so),证明物理内存已经不能满足系统需求,系统必须把物理内存的页面交换到磁盘中去。
  由此可以得到这样的结论:该主机上的物理内存已经不能满足系统运行的需要,内存已成为该系统性能的一个瓶颈。
  ps:对于java程序,内存瓶颈可以通过heap dump后使用mat分析
  磁盘瓶颈:
  iostat查看IO信息。如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。
  另外还需要注意iowait这个值,iowait 值高就意味着磁盘缓慢或负载过大。还有不要信任svctm这个字段。
  监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.
  ps:磁盘瓶颈可以通过pidstat -d 定位程序
  2.如何理解CPU、内存、磁盘的关系?
  这些子系统之间关系是彼此联系,相互彼此依赖的
  1.对于进程来说,数据是存放在内存中的,进程的运行需要使用CPU,进程读写数据需要跟磁盘打交道。
  2.当内存不足时需要跟磁盘进行页(page)交换,swap交换,从而产生磁盘IO。po,so释放物理内存,pi,si增加物理内存使用。交换分页的过程需要占用cpu时间。 (内存占用过高)
  3.当磁盘IO负载过高时,需要监控swap和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈。磁盘的相当慢的,当iowait 增长,表示CPU花费大量的时间在等待磁盘IO,此时CPU Bound的应用处理将受到影响(磁盘IO过高)
  3.如何理解paging in / paging out ?
  在Linux内存管理中,主要是通过“调页Paging”和“交换Swapping”来完成上述的内存调度。调页算法是将内存中最近不常使用的页面换到磁盘上,把活动页面保留在内存中供进程使用。交换技术是将整个进程,而不是部分页面,全部交换到磁盘上。
  分页(Page)写入磁盘的过程被称作Page-Out,分页(Page)从磁盘重新回到内存的过程被称作Page-In。当内核需要一个分页时,但发现此分页不在物理内存中(因为已经被Page-Out了),此时就发生了分页错误(Page Fault)。
  当系统内核发现可运行内存变少时,就会通过Page-Out来释放一部分物理内存。经管Page-Out不是经常发生,但是如果Page-out频繁不断的发生,直到当内核管理分页的时间超过运行程式的时间时,系统效能会急剧下降。这时的系统已经运行非常慢或进入暂停状态,这种状态亦被称作thrashing(颠簸)。
  可以通过vmstat -s 查看 paged in/out 数量
  4.如何监控操作系统的资源?(可用一个操作系统做例子)
  (把简历上部分内容直接贴出来了,懒的整理了)
  CPU监控:top(利用率), uptime(运行队列数), vmstat(上下文切换数), jprofile(方法占用cpu时间百分比)
  内存监控:top, free(利用率), vmstat(page和swap交换), pidstat -r和sar -B(page fault), jmap -heap(堆dump), mat和jprofiler(查看对象)
  磁盘监控:iostat(%util), top(iowait%), pidstat -d
  网络监控:netstat(连接数), nethogs(流量), wireshark和tcpdump(抓包)
  JVM监控:jstat(gc), jmap(堆dump), jstack(线程dump), jprofiler和visualvm(剖析工具)
  nmon(长时间全局收集数据)
  5.如何理解内存管理和线程调度?(可用一个操作系统做例子)
  不会
  6.如何理解上下文切换(context switch)?(可用一个操作系统做例子)
  每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程,Linux采用抢占式调度。即为每个线程分配一定的执行时间,当到达执行时间,线程中有IO阻塞或高优先级线程要执行时,Linux将切换执行的线程,在切换时要存储目前线程的执行状态,并恢复要执行的线程状态,这个过程称之为上下文切换。对于java应用,典型的是在进行文件IO操作,网络IO操作,锁等待或线程sleep时,当前线程会进入阻塞或者休眠状态,从而触发上下文切换,上下文切换过多会造成内核占用过多的CPU使用,使得应用的响应速度下降。
  vmstat其中cs那一列
  7.如何理解磁盘IO?(可用一个操作系统做例子)
  磁盘IO速度是非常慢的,linux内核就是要尽量降低IO
  内存不足时会进行页交换,产生磁盘IO
  CPU Bound类型应用,当磁盘IO过多,iowait过大时会影响性能。

posted @ 2014-08-22 09:41 顺其自然EVO 阅读(602) | 评论 (0)编辑 收藏

仅列出标题
共394页: First 上一页 60 61 62 63 64 65 66 67 68 下一页 Last 
<2024年11月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜