1. HTTP/HTTPS协议

        ·   你应该去了解什么是http协议

        ·   什么是GET, POST, session, cookie等

        ·   Get与Post的区别是什么?

        ·   session与cookie的区别是什么?

        ·   什么是无状态？

2. 浏览器机制

        ·   理解浏览器在处理javascript及渲染CSS的机制

        ·   了解IE与其他浏览器的差异

        ·   为什么兼容性测试时需要特别关注IE

        ·   浏览器在加载javascript，CSS有时在前面有时在后面，为什么？

        ·   加载顺序会对视觉和使用上有什么影响呢？

        ·   各种浏览器使用的内核分别是什么？

3. web架构

      也许你会说这是架构师的事儿，没错，基本是他们的活儿，但是理解了web架构能让我们测试的更深入。你要知道：

        ·   软件出错时怎么个报警法？是否有详尽的log记录？

        ·   服务器缓存机制如何？

        ·   数据库如何主从同步，如何备份的？

        ·   集群如何处理session的？

4. 安全

       因为web应用的特殊性，你需要掌握的安全技能：

        ·   如何进行SQL注入测试？如何防止SQL注入？

        ·   什么是跨站脚本攻击(XSS)？如何开展此类测试，应该如何防范XSS？

        ·   什么是DOS，DDOS？开发人员如何coding来避免？

        ·   传输哪些重要数据时需要加密

        ·   哪些页面需要使用SSL/https来加密传输    

        ·   什么是跨站伪造请求攻击 cross site request forgeries (XSRF)，如何避免？

        ·   安全证书的意义，浏览器在证书失效时提示是怎样的？

5. web性能

       你应该知道的web性能知识：

        ·   web前端的性能极大影响了用户，如何观察这些数据？CSS和图片的合并压缩的意义

        ·   了解浏览器cache及服务端cache

        ·   对于图片请求过多的网站，为何要把图片放置在不同的域名下，最好使用CDN？

        ·   确 认你的网站有一个 favicon.ico 文件放在网站的根下，如 /favicon.ico.每当有用户收藏网站/网页时，浏览器会自动请求这个文 件，就算这个图标文件没有在你的网页中明显说明，浏览器也会请求。如果你没有这个文件，就会出大量的404错误，这会消耗你的服务器带宽，服务器返回 404页面会比这个ico文件可能还大

        ·   知道单个页面的http请求数越少越好

        ·   顺序加载和异步加载的优劣，何时需要使用AJAX？懒加载的意义，用于何处？

        ·   如何使用性能测试工具Jmeter/LR等开展性能测试？

6. SEO

      只要是WEB应用，都会有SEO，因为它是种免费的搜索引擎推广方式，否则在百度搜索你们网站，是没有结果的。所以，你需要知道：

        ·   XML sitemap的意义，可以让搜索引擎了解你的网站地图

        ·  了解 robots.txt 和搜索引擎爬虫是如何工作的

        ·   搜索引擎喜欢什么样的URL？

        ·   重定向301和302对于搜索引擎的意义？

        ·   网页Meta信息中title，description等的重要性

7. 用户体验

网站的功能只是说实现了什么，而用户体验则诠释了做的有多好，用户使用起来是否有难度，是否会爱上这个网站（当然12306除外，咯咯）

        ·   访问网站的用户操作行为是怎么样的？页面的访问频率占比如何？因为测试的精力和侧重点也要根据这个数据而定    

        ·   网站部署时是否会影响到用户使用，如何避免？

        ·   不要直接显示不友好的错误提示，是否有友好的提示信息？

        ·   web应用不能泄漏用户的隐私信息

        ·   页面是在当前页打开还是另开一个tab？

        ·   页面元素的布局如何影响到用户体验的？

8. 使用工具

        ·   HttpWatch，基于IE的网络数据分析工具，包括网页摘要，Cookies管理，缓存管理，消息头发送/接受，字符查询，POST 数据和目录管理功能等

        ·   FireBug，用途同上，基于firefox的

        ·   Yslow，前端网站性能工具，显示测试结果的分析,分为等级、组件、统计信息

        ·   Fiddler，强大的web前端调试工具，它能记录/拦截所有客户端和服务器的http和https请求，允许你监视，设置断点，甚至修改输入输出数据，也可用于安全测试

        ·   Chrome扩展程序：浏览器兼容性检测工具，分析网站的兼容性情况

        ·   ShowIP：显示访问网站的IP，web测试中你是否经常因为访问的网站IP不对，而被开发人员BS呢？它能帮助到你。

　　Cookie是Web产品测试过程中不可缺少的一部分，我们需要通过Cookie信息辨别用户，得到属于自己的结果数据，例如DWR接口测试过程中，需要在请求头信息中传入测试用户的cookie信息，才可以得到该用户学习的课程，发表的博客，或者关注的用户等。Cookie信息通过模拟登陆操作就可以获得。但是，你有没有注意到你获得的Cookie是由什么组成的？是否包含NTES_SESS信息，是否包含SessionID信息？

　　NTES_SESS是URS返回的Cookie信息，NTESSTUDYSI是云课堂返回的Session信息，NTESSTUDYSI存储SessionID信息，不同的产品会配置不同的变量名。这个信息对于接口测试来说并不是必须的，但是却会在性能测试过程中起到很关键的作用。Cookie和Session有什么区别，为什么性能测试过程中必须需要Session信息？下面，我们一一阐述：

　　Cookie是什么：

　 　cookie是小甜饼、小型文本文件，因为HTTP协议是无状态的，浏览器无法区分这次请求来自于哪个浏览器，因此产生了随着HTTP请求一起被传递给 服务器的Cookie信息。Cookie是保存在客户端的，存在内存中的cookie，浏览器关闭后就消失了，存在时间是短暂的；存在硬盘中的 Cookie，但存储时间长度超过过期时间或者用户手动清除时，cookie信息会消失。

　　Session是什么：

　 　Session是会话，当用户第一次对网站服务器发生请求时，服务器会创建Session信息，生成SessionID用来唯一标识用户，并会把该 SessionID返回给客户端浏览器（只存在内存，并不存在硬盘中），在会话结束之前的每次请求，浏览器会自动将该SessionID附加在请求头信息 中，服务端接受请求时，检测是否存在SessionID（不存在或者Session过期都会重新生成Session），并通过该SessionID以键值 对的方式查询用户信息。服务端的Session使用类似散列表的结构存储用户信息。

　　Session的常见实现形式是会话 Cookie（Session Cookie），即未设置过期时间的Cookie，这个Cookie的默认生命周期为浏览器会话期间，只要关闭浏览器窗口，Cookie就消失了，这种形 式的Session是和Cookie绑定在一起的。而平常所说的Cookie主要指的是另一类Cookie——持久Cookie（Persistent Cookies）。持久Cookie是指存放于客户端硬盘中的Cookie信息（设置了一定的有效期限）。持久Cookie一般会保存用户的用户ID，该 信息在用户注册或第一次登录的时候由服务器生成包含域名及相关信息的Cookie发送并存放到客户端的硬盘文件上，并设置Cookie的过期时间，以便于 实现用户的自动登录和网站内容自定义。

　　我们在执行接口测试之前，首先会通过URS得到用户Cookie信息，这份Cookie信息中至 少会得到NTES_SESS字段对应的Values值，如果在获取Cookie时，我们同时跳转到产品页面，向该产品服务器发送请求（例如云课堂），那么 在我们得到的Cookie信息中同样存在NTESSTUDYSI字段，该字段就是该产品的Tomcat服务器产生的32位的SessionID +jvmRoute设置的后缀名。在做接口测试时，如果请求头中没有传入SessionID信息，那么每次执行时，Tomcat都会重新生成一份 Session；即便你传入该SessionID信息，如果SessionID过了超时时间设置，Tomcat还是会重新生成一份，Tomcat默认的 Session过期时间为30Min。

　　性能影响

　　虽然只是一个小小的SessionID，却会对性能测试的产生很大的影响：

　　1、Session缺失：

　　在做Lofter产品的性能测试时，测试getHomePage接口，发现响应时间比较慢，JVM内存在测试过程中一直增长，Young GC收集不过来，Old区内存不断增长，最终会导致频繁Full GC，使用Jmap定位到堆内存中java.util.concurrent.ConcurrentHashMap$Segment 对象不断增加，但是并不知道这个对象时谁在什么时候产生的。我们Dump出来此时的堆内存，使用MAT (Memory Analyzer Tool)工具进一步分析，到底是什么操作产生了大量的ConcurrentHashMap$Segment。

　　由上图可以看到这个对象是由org.apache.catalina.session.StandardManager产生的，session.StandardManager就是存储Session的容器。

通过了解Session的原理得知，我们在测试过程中，只是传入了Cookie信息，在Cookie中没有包含SessionID信息，所以每次请 求时，Tomcat都会检查是否存在该标识信息，如果没有则会创建。如果我们测试过程中有几十万次请求，那么Tomcat会创建几十万个Session信 息，假设一条Session需要2K的数据，那几十万的Session可能会使得Session容器占用上百兆的空间。同时需要注意，因为我们每个请求都 会创建Session，这个Session是创建了以后不会被使用的(下次请求中依然没有携带SessionID)，即垃圾Session，但是垃圾 Session在过期之前是会一直存在内存中的，默认的Session保存时间是30Min，这样的垃圾Session会在内存中保存至少30Min，如 果在这30Min中内我们不停的发送请求，Session容器占用的内容空间会 不断扩大，最终会影响我们的测试结果。

　　2、Session过期

　　即便我们在请求中加入了SessionID，但是还可能会产生不停的创建Session问题，这是为什么？因为Session是存在过期时间 的，默认的Tomcat中web.xml中设置的session过期时间为30Min，如果我们得到的SessionID在30Min后使用，依据 Tomcat的Session机制，首先会检查是否存在SessionID，如果有的话，检测是否过期，如果传入的SessionID已经过 期，Tomcat还是会每次都自动生成Session信息。

　　Mark，Session的过期时间有三种设置方式：一种是Tomcat的配置文件web.xml中设置，一种是webroot项目代码中的配 置文件web.xml中设置，一种是代码中设置session.setMaxInactiveInterval(15*60)，所以我们在测试中要记得检 测和确认这三个地方。

　　3、SessionID后缀不匹配

　　在测试云课堂项目中，我明明已经修改了每个地方的Session过期时间，请求中传入了没有过期的SessionID，可是为什么还是会不停的创建Session？

　　一般我们的产品架构是Nginx+Tomcat方式，静态请求走Nginx，动态请求通过Nginx访问到Tomcat。Nginx处理 Session采用了session sticky方案，需用到第三方模块jvm_route，需要在Nginx的配置文件中upstream.conf中设置：

　　该配置文件中配置了一个Nginx连接两个Tomcat，当请求过来时，会依据SessionID中的后缀来查找请求发送到哪个Tomcat， 例如NTESSTUDYSI=1816E5ECBC052F6ABA420FEE7B06DA86.qa18-8010;就会把带这个SessionID 的请求发送到 10.120.36.68(qa18)这台机器上去。

　　在qa18这台机器的Tomcat配置文件server.xml中，会设置jvmRoute="qa18-8010"，这样保证生成的SessionID的后缀是qa18-8010，如果这个两个后缀不一致的话，同样会出现问题。

　　例如如果Nginx配置文件中upstream.conf中设置的srun_id=qa18-8010，而tomcat配置文件中设置的 jvmRoute="qatest18-8010"，那么获取Cookie得到的SessionID后缀则为qatest18-8010，当发送请求到 Nginx时，检测到SessionID的后缀和设置的server服务器无法匹配，则会丢失session，使得发送到Tomcat的动态请求依旧是没 有Session信息的请求，造成session丢失，测试过程中还会有session不断的创建。

　　页面性能测试则是针对于页面性能优化而开展的一种性能测试，目的是对Web系统的页面进行测试以确认系统页面是否会影响系统的性能并为页面的优化提供依据与建议，最终提升系统的整体性能表现，提高用户体验满意度。可见，Web系统页面性能测试是相对Web系统后台测试的另外一种性能测试，是Web系统性能测试的一个重要部分。

　　二、页面性能测试必要性

　 　相对于C/S架构的应用系统，Web应用系统所有数据都需要从服务器端下载，虽然浏览器有缓存机制，但客户每次访问仍然需要下载大量的数据。特别是用户 对系统要求越来越高，除了要求功能完备，对界面的美观、易用性也提出了更高的要求，越炫的页面也就意味着页面中要包含更多的脚本、样式表、图片和 Flash，页面的数据量也就越大，这对Web系统的性能提出了极大的挑战。

　　曾经有个在线打印服务的应用提供商说他们的系统不需要关注 系统性能问题，没有必要进行性能测试，因为他们可以购买足够多的服务器来支撑系统；不少业界同行也认为只要有足够多的服务器资源，性能就不会存在问题。其 实不然，他们都只关注到了应用系统的后台性能表现，而忽略了页面对系统整体性能的影响。举个例子，当一个页面中包含几百个请求，页面中没有经过优化的 javaScript文件、CSS 文件与图片件大小达到10MB，即使当前只有一个用户在访问该系统，页面的访问速度也会慢得惊人，纵使增加再多的服务器也不见得会有明显的性能提升。

　 　可见，对Web应用系统的页面进行性能测试和优化是非常有必要的。只有通过对页面的性能测试，发现页面存在的性能问题并根据性能测试结果进行页面优化以 提升页面的加载性能，从而提升系统的整体性能。在应用系统高并发访问时，更能体现出Web页面优化后所带来的系统整体性能提升效果。

　　2种方式来提升你的web 应用程序的速度：

　　● 减少请求和响应的往返次数

　　● 减少请求和响应的往返字节大小。

　　减少请求和响应的往返次数：

　 　HTTP缓存是最好的减少客户端服务器端往返次数的办法。缓存提供了提供一种机制来保证客户端或者代理能够存储一些东西，而这些东西将会在稍后的 HTTP 响应中用到的。（即第一次请求了，到了客户端，缓存起来，下次如果页面还要这个JS文件或者CSS文件啥的，就不要到服务器端去取下来了，但是还是要去服 务器上去访问一次，因为请求要对比ETAG值，关于这个值，我将会在下次翻译中介绍其作用）这样，就不用让文件再次跨越整个网络了。

　　缓存相关的请求头

　　为了提高性能，微软的IE和其他的web客户端总是想尽办法来维持从远程服务器上下载下来的本地的缓存。

　　当客户端需要一个资源（html，css.js…），他们有3种可能的动作：

　　1、发送一个一般的HTTP请求到远程服务器端，请求这个资源。

　　2、发送一个有条件的HTTP请求到服务器，条件就是如果它不同于本地的缓存版本。

　　3、如果缓存的拷贝可用，就使用本地的缓存资源。

　　当发送一个请求，客户也许会使用如下的几个HEADER

　　减少请求肯响应往返的字节大小：

　　1、使用更少的图画

　　2、将所有的CSS浓缩到一个CSS文件中

　　3、将所有的脚本浓缩到一个JS文件中

　　4、简化你的页时间

　　5、使用HTTP压缩

　　第一种是通过HTTP代理的方式来截取客户与服务器之间的通讯。

　　此类的工具非常的多，如：

　　charles是一个HTTP代理/ HTTP监视器/使开发人员可以查看所有的计算机和互联网之间的HTTP和SSL/ HTTPS流量的反向代理。这包括请求，响应和HTTP标头（其中包含的cookies和缓存信息）。

　　charles界面清爽，采用中国的瓷器为logo，给人的感觉简洁高雅。而且使用也非常简单。进入下载页面，选择你适合你的版本，安装也非常简单，一路“next”就OK了。

　　点击工具栏上的“红色”按钮，就自动的记录你浏览器访问的所有网站。

　　Fiddler是一个Web调试代理，记录所有的HTTP（S）之间的计算机和互联网的交通。提琴手允许您检查交通，设置断点，和“捣鼓”传入或传出数据。菲德勒包括一个强大的基于事件的脚本子系统，并可以使用任何。NET语言扩展。

　　Fiddler是免费软件，可以调试，从几乎任何应用程序，支持代理，包括IE浏览器，谷歌Chrome，苹果Safari，Mozilla Firefox中，歌剧，还有数千交通。您也可以像Windows电话，iPod/ iPad和其他流行的设备调试的交通。

　　Fiddler2相比Charles功能要更强大一些。当然了，如果单单把他们理解成页面性能测试工具有此片面，尤其Fiddlers2功能强大，当然了，我也没有深究，在此就不过多评论了。

　　先看一图，再看下文

　　这个当然就是压力过程中带宽的使用率了，我们的带宽是1Gbps的，合计传输速率为128MB/s，也正因为这个就让我越来越疑惑了，不过通过压力过程中的各项数据我又不得不相信。

　　在看看测试页面的大小和请求，如下图所示：

　　这是通过httpwatch检测得出来的，页面传输内容的大小为652154Byte，请求数为149次，也就是说加载一次页面就大概需要请求这么多次请求，传输这么大的内容，当然这里剔除缓存机制来分析的。

　　场景设计：

　　1、并发用户200

　　2、每20秒加载10个用户

　　3、全部用户加载完成之后，持续运行10分钟

　　监控目标：TPS、响应时间、点击率、吞吐率、内存、CPU和网络带宽

　　测试分析结果如下图：

　　这里的可以得出平均点击率为11952.139次/s，而吞吐率为73178737byte，大约为73MB/s，TPS：720/s，这里的错误后面再说。

　　这里的响应时间很显然没有上去，说明压力没有传到页面上，而上面的错误也同时可以证实，报错基本都是请求被拒绝，也就说后面没有请求导致页面没有压力，响应时间就无效了。

　通过监控得到系统资源占用率数据有：

　　CPU：25～30%

　　内存：20%

　　网络带宽：70～95%

　　通过Httpwatch在压力过程监控的页面响应时间为：6.454s

　　通过结合虚拟用户、点击率、吞吐率和响应时间的曲线图分析得出如下总结：

　　当虚拟用户加载到150的时候，点击率和吞吐率此时处于峰值，且网络带宽达到90%以上，当虚拟用户继续加载的时候，点击率和吞吐率均都开始下 降，此时场景运行开始报错，提示信息为服务器连接被拒绝。通过分析，处于峰值只有网络带宽，为90%以上，而对比此处的吞吐率值恰为95MB/s左 右，1Gbps的网络带宽传输速率为128MB/s，从而表明由于吞吐量过大，占用了大量的带宽资源，导致后续的虚拟用户无法得到服务器的资源，而致使请 求被拒绝。从最后的页面响应时间来看，系统的压力并没有被承接到页面上，而是由于过大的吞吐量吞噬了网络带宽，导致最终无法有效地完成测试任务。

　　第二部分，测试分析

　　如上的结果确实是证实了网络带宽不够用，抱着这个不大相信的疑问，我在群里跟大家讨论了一番，当然大家的给出结论也都是一致，也有建议修改系统 的参数，释放所有的带宽等；还有就是分析页面，当然这个我个人认为是比较切实的路径，毕竟1Gbps的带宽，如果再扩从的话也不大现实，所以还是要靠优化 程序着手。

　　我又继续通过httpwatch工具对其他门户网站首页进行检测，发现页面容量差不多，但是从请求上来讲，腾讯和同花顺的首页请求都只有80左 右，而我们的却有149个请求，这里的请求数就直接决定于点击率的多少，从这里我们就可以发觉，并不是对所有的压力测试来说，每秒钟的点击率越高，对应的 吞吐率越大就说明系统的性能越好，必须相对请求数而言来进行分析。从另一个层面上来说点击率越高是说明程序效率好，但是从本身来讲，如果一个页面本身的请 求就很多，那最后的点击率必然会大，大到最后的结果就是页面内容累计容量就越大，导致传输带宽的不断放大，当然就带宽不够用了。如果一定程序上降低了单个 页面的请求数量，那页面的执行效率必然会越高，而需要结合整体页面的容量大小来衡量。

　　最后，我给开发提出的建议，还是需要对程序、页面等进行优化，优化硬件还有待考量，优化建议如下：

　　1、降低页面的请求次数

　　2、优化页面中各个元素的容量大小，结合Page Speed和YSlow工具进行优化测试

　　3、多方面结合缓存机制

　　不知道以上的分析结果是否准确，但让我从性能分析的思路上又走出了一个绝地，不要放过每一个细节，也许那就是拐点。

选择Web容器是否和Jprofiler一起运行：

默认即可

配置提示：

 在“远程控制”的时侯要仔细阅读一下。

然后选择立即起动，开始运行。

点击“OK”，我们可以看到另外一个小窗口出来了：

Jprofiler的窗口为：

这样我们就可以进行监控了！

(五)    开始测试

1． 在IE地址栏中输入：http://localhost/test/init1.jsp，执行一次，我们可以在内存视图中看到cn.test.TestBean对象被创建了10000次：

2.标记现在的状态，然后再执行init1.jsp和,init2.jsp可以让我们找到哪些类在调用后没有被释放（很重要！！！）

查看哪些类被发生了变化：

红色的变成是发生变化的对象及其数量。

我刚才执行了4次init1.jsp和1次init2.jsp，正好产生了50000个TestBean对象，和图示显示的一样。

3． 过一会后，按F4键进行垃圾回收。但回收完成后，这些对象依然存在，说明某些地方对这个类的引用没有被释放！

4． 找出是哪些地方使用了TestBean类，并且没有释放它们

在cn.test.TestBean对象上点击右键选择“Take Heap Snapshot for Selection”，观察它的heap

下一步：

点击“OK”：

在该类中点击右键，在出现的菜单中选择“Use Selected Objects”：

出现如下窗口：

选择”Allocations”，点击“OK”,然后我们要的结果就出来了

图中显示调用此类的地方是init1.jsp和init2.jsp，并且各自占用的比率都列出来了。

既然问题的所在找出来了，接下来就该去解决问题了！

（五）总结

其实，我们在测试内存占用时还可以另外写一个释放内存的JSP文件来配合测试，会更清楚一些：

Free.sjp

<%@pagelanguage="java"import="java.util.*,cn.test.*"pageEncoding="ISO-8859-1"%>

<!DOCTYPEHTMLPUBLIC"-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

 <head>

   <title>init</title>

 </head> 

 <body>  

   <%TestMain.list.clear();%> collection OK!

 </body>

</html>

在点击完init1.jsp或init2.jsp后，可以看到内存是TestBean对象的数量增加了，然后执行free.sjp，接着再执行F4进行垃圾回收，立刻可以看到TestBean对象被释放掉了。

JProfiler学习笔记

一、安装JProfiler

      从http://www.ej-technologies.com/下载5.1.2并申请试用序列号

二、主要功能简介

1．内存剖析Memory profiler

JProfiler的内存视图部分可以提供动态的内存使用状况更新视图和显示关于内存分配状况信息的视图。所有的视图都有几个聚集层并且能够显示现有存在的对象和作为垃圾回收的对象。

• 所有对象
  显示类或在状况统计和尺码信息堆上所有对象的包。你可以标记当前值并显示差异值。
• 记录对象Record objects
  显示类或所有已记录对象的包。你可以标记出当前值并且显示差异值。
• 分配访问树Allocation call tree
  显示一棵请求树或者方法、类、包或对已选择类有带注释的分配信息的J2EE组件。
• 分配热点Allocation hot spots
  显示一个列表，包括方法、类、包或分配已选类的J2EE组件。你可以标注当前值并且显示差异值。对于每个热点都可以显示它的跟踪记录树。

2．堆遍历Heap walker

在JProfiler的堆遍历器(Heap walker)中，你可以对堆的状况进行快照并且可以通过选择步骤下寻找感兴趣的对象。堆遍历器有五个视图：

• 类Classes
  显示所有类和它们的实例。
• 分配Allocations
  为所有记录对象显示分配树和分配热点。
• 索引References
  为单个对象和“显示到垃圾回收根目录的路径”提供索引图的显示功能。还能提供合并输入视图和输出视图的功能。
• 数据Data
  为单个对象显示实例和类数据。
• 时间Time
  显示一个对已记录对象的解决时间的柱状图。

3．CPU剖析CPU profiler

JProfiler提供不同的方法来记录访问树以优化性能和细节。线程或者线程组以及线程状况可以被所有的视图选择。所有的视图都可以聚集到方法、类、包或J2EE组件等不同层上。CPU视图部分包括：

• 访问树Call tree
  显示一个积累的自顶向下的树,树中包含所有在JVM中已记录的访问队列。JDBC,JMS和JNDI服务请求都被注释在请求树中。请求树可以根据Servlet和JSP对URL的不同需要进行拆分。
• 热点Hot spots
  显示消耗时间最多的方法的列表。对每个热点都能够显示回溯树。该热点可以按照方法请求，JDBC，JMS和JNDI服务请求以及按照URL请求来进行计算。
• 访问图Call graph
  显示一个从已选方法、类、包或J2EE组件开始的访问队列的图。

4．线程剖析Thread profiler

对线程剖析，JProfiler提供以下视图:

• 线程历史Thread history
  显示一个与线程活动和线程状态在一起的活动时间表。
• 线程监控Thread monitor
  显示一个列表，包括所有的活动线程以及它们目前的活动状况。
• 死锁探测图表Deadlock Detection
  显示一个包含了所有在JVM里的死锁图表。
• 目前使用的监测器Current monitor useage
  显示目前使用的监测器并且包括它们的关联线程。
• 历史检测记录History usage history
  显示重大的等待事件和阻塞事件的历史记录。
• 监测使用状态Monitor usage statistics
  显示分组监测，线程和监测类的统计监测数据。

5．VM遥感勘测技术VM telemetry

观察JVM的内部状态，JProfiler提供了不同的遥感勘测视图，如下所示:

• 堆Heap
  显示一个堆的使用状况和堆尺寸大小活动时间表。
• 记录的对象Recorded objects
  显示一张关于活动对象与数组的图表的活动时间表。
• 垃圾回收Garbage collector
  显示一张关于垃圾回收活动的活动时间表。
• 类Classes
  显示一个与已装载类的图表的活动时间表。
• 线程Threads
  显示一个与动态线程图表的活动时间表。

三、实战

(一)任务目标

找出项目中内存增大的原因

 （二）配置说明

         操作系统：Windows2003

             Web容器：Tomcat5.0.23

             JDK版本：sun1.4.2

             监控类型：本地

             Jprofiler安装路径：D:/jprofiler5

             Tomcat安装路径：D:/Tomcat5

(三) 测试项目

1． 新建WEB项目test

2． 建包cn.test

3． 在该包下建类文件TestMain.java和TestBean.java

package cn.test;

public class TestBean {

  String name = "";

}

packagecn.test;

importjava.util.ArrayList;

publicclassTestMain {

publicstaticArrayListlist=newArrayList(); //存放对象的容器

public static int counter = 0;    //作统计用

    }

      4.建测试用的JSP文件init1.jsp、init2.jsp

Init1.jsp（每次执行都创建1万个TestBean对象）

<%@pagelanguage="java"import="cn.test.*"pageEncoding="ISO-8859-1"%>

<!DOCTYPEHTMLPUBLIC"-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

 <head>

   <title>init</title>

 </head>

 <body><%

   for(inti=0;i<10000;i++){

      TestBean b =newTestBean();

      TestMain.list.add(b);      

   }

   %>

   SIZE:<%=TestMain.list.size()%><br/>

   counter:<%=TestMain.counter++%>

 </body>

</html>

Init2.jsp和init1.jsp一模一样即可（后面有用）。

(四)    配置测试用例

1． 点击d:/jprofiler5/bin/jprofiler.exe

2． 执行菜单SessionàIntegration WizardsàNew ServerIntegration

 

选择是本地测试还是远程测试：

选择tomcat运行的脚本文件：

选择虚拟机的类型:

选择监控端口：

用默认的即可

选择Web容器是否和Jprofiler一起运行：

默认即可

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在where及order by涉及的列上建立索引。

 2.应尽量避免在where子句中对字段进行null值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

 3.应尽量避免在where子句中使用！=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

 4.应尽量避免在where子句中使用or来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

 可以这样查询：

 5.in和not in也要慎用，否则会导致全表扫描，如：

 对于连续的数值，能用between就不要用in了：

 6.下面的查询也将导致全表扫描：

 若要提高效率，可以考虑全文检索。

 7.如果在where子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

 可以改为强制查询使用索引：

 8.应尽量避免在where子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：

 应改为：

 9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

 应改为：

10.不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

12.不要写一些没有意义的查询，如需要生成一个空表结构：

 这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：

13.很多时候用exists代替in是一个好的选择：

 用下面的语句替换：

14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。

15.索引并不是越多越好，索引固然可以提高相应的select的效率，但同时也降低了insert及update的效率，因为insert或update时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

16.应尽可能的避免更新clustered索引数据列，因为clustered索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新clustered索引数据列，那么需要考虑是否应将该索引建为clustered索引。

17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

18.尽可能的使用varchar/nvarchar代替char/nchar，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

19.任何地方都不要使用select * from t，用具体的字段列表代替“*”，不要返回用不到的任何字段。

20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。

21.避免频繁创建和删除临时表，以减少系统表资源的消耗。

22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。

23.在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免造成大量log，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。

25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。

26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。

27.与临时表一样，游标并不是不可使用。对小型数据集使用FAST_FORWARD游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。

28.在所有的存储过程和触发器的开始处设置SET NOCOUNT ON，在结束时设置SET NOCOUNT OFF。无需在执行存储过程和触发器的每个语句后向客户端发送DONE_IN_PROC消息。

29.尽量避免大事务操作，提高系统并发能力。

如何配置回收

要点只有在工作进程隔离模式下运行时才能使用这个 IIS 6.0 功能。

在工作进程隔离模式中，可以将 IIS 配置为定期重新启动分配给应用程序池的工作进程，从而允许您回收有问题的 Web 应用程序。回收可以使存在问题的应用程序保持顺利运行，尤其是在无法修改应用程序代码时。这确保这些应用程序池保持正常运行，且可以恢复系统资源。

您可以将工作进程配置为基于经过的时间、服务的请求数、计划的时间或内存利用率来重新启动，也可以将它们配置为按需启动。

要点您 必须是本地计算机上 Administrators 组的成员或者必须被委派了相应的权限，才能执行下列步骤。作为安全性的最佳操作，请使用不属于 Administrators 组的帐户登录计算机，然后使用运行方式命令以管理员身份运行 IIS 管理器。在命令提示符下，键入 runas /user:administrative_accountname "mmc %systemroot%\system32\inetsrv\iis.msc"。

配置要在经过一定时间后回收的工作进程

1.在 IIS 管理器中，展开本地计算机，展开“应用程序池”，右键单击该应用程序池，然后单击“属性”。
2.在“回收”选项卡上，选中“回收工作进程(分钟)”复选框。
3.单击向上或向下箭头，设置在经过多少分钟后回收工作进程。
4.单击“确定”。

配置要在处理一定数量的请求后回收的工作进程

1.在 IIS 管理器中，展开本地计算机，展开“应用程序池”，右键单击该应用程序池，然后单击“属性”。
2.在“回收”选项卡上，选中“回收工作进程(请求数目)”复选框。
3.单击向上或向下箭头，设置在处理多少请求后回收工作进程。
4.单击“确定”。

配置要在计划的时间回收的工作进程

1.在 IIS 管理器中，展开本地计算机，展开“应用程序池”，右键单击该应用程序池，然后单击“属性”。
2.在“回收”选项卡上，选中“在下列时间回收工作进程”复选框。
3.单击“添加”向列表中添加一个时间，单击“删除”从列表中删除一个时间，或者单击“编辑”更改将回收工作进程的现有时间。
4.单击“确定”。

注意如果将回收设置为在计划的时间进行，则在系统时间发生变化时，回收可能不按计划进行。为了避免无意更改计划的回收时间，请在系统时间更改之后立即回收计划的工作进程。

配置要在消耗一定内存量之后回收的工作进程

1.在 IIS 管理器中，展开本地计算机，展开“应用程序池”，右键单击该应用程序池，然后单击“属性”。
2.在“回收”选项卡上，在“内存回收”下，选中“最大虚拟内存(兆)”或“最大使用的内存(兆)”复选框。
3.单击向上或向下箭头，设置内存限制。
4.单击“确定”。

================================================================================================================================

附上几个不错的IIS配置的链接：

http://www.ip126.com/Article/2009/200907/7338.html

http://www.ithov.com/server/website/web/77393.shtml

http://www.jb51.net/article/27982.htm

   从客户现场回公司了，有时间学习了下日语，唉，日本人真的不怕麻烦，几个简单的词，要说一大串，呵呵，好拗口呀！