什么是A/B测试?

A / B测试的核心就是：确定两个元素或版本（A和B）哪个版本更好，你需要同时实验两个版本。最后，选择最好的版本使用。

网络上的A / B测试，即你设计的页面有两个版本（A和B），A为现行的设计（称为控制） ， B是新的设计。比较这两个版本之间你所关心的数据（转化率，业绩，跳出率等） 。最后，您选择效果最好的版本。

测试哪些东西?

你要选择什么去测试取决于你的目标。例如，如果你的目标是增加顾客数量，那么您可能测试下列内容：注册表单数量，字段类型要求，隐私政策等。在这种情况下A / B测试的目标是要弄清楚什么阻止了游客注册。需要填写的表单的数量？用户的隐私？还是该网站做了让游客不信任的事情？所有这些问题都可以通过一个个A/B 测试获得答案。

每一个A / B测试内容都是独一无二的，单通常测试一下这些内容：

• 行动按钮的措辞，大小，颜色和位置，
• 标题或产品说明，
• 表单的数量和字段类型，
• 网站的布局和风格，
• 产品定价和促销活动，
• 着陆和产品页面上的图片，
• 页面上文字的长度（少Vs多）。

一旦你决定要测试什么，下一步当然是要选择一个合适的测试工具。如果你想要一个基础的免费工具，可以使用Google Website Optimizer。如果你想要功能更加强大的工具，可以使用Visual Website Optimizer  。其他的一些选择都是可以的，建立试验在所有工具中都很相似，所以我们只需讨论一种即可。

你可以通过两种方法建立A / B测试：

• 在页面测试加载前替换元素
  如果你测试的是页面上的单个元素，如注册按钮，然后需要在测试工具中设置按钮。当测试时，在A / B工具将在页面给用户前随机替换按钮。
• 重定向到另一页面
  如果你想通过A / B测试整个页面，比如说，一个绿色的主题和一个红色主题，那么你就需要创建和上传新的页面。例如，如果您的主页是 http://www.example.com/index.html，那么你需要创建另外一个页面 http://www.example.com/index1.html。当测试运行时，您的测试工具将一部分访问者重定向到第二个网址。

一旦您使用了上面的两种变换方法，下一步是建立您的转换目标。通常，你会得到一个JavaScript代码，您可以复制并粘贴到一个需要游客到达的目标网页。例如，如果您有一个电子商务网站，你正在测试的“立即购买“按钮的颜色，然后您的转换目标将是购买成功后的“谢谢您“页面。

在转换事件发生的同时，在A / B测试工具，记录了哪种页面显示给了访问者。经过足够数量的游客，您可以确定哪个页面带来了最多的转化！建立和运行的A / B测试，其实很简单。

该做什么和不该做什么

虽然A / B测试是超级简单的概念，但是请记住，以下这些都只是我自己的经验。

注意事项

• 不要分开你的测试情况。始终两个版本同时进行测试。如果您第一星期测试第一版本，第二星期测试第二个版本，你就错了。有可能B版本带来的流量更糟糕，但是带来了更好的业绩，因为两个版本之间的流量始终存在不一样。
• 不要结束得太早。有一个概念叫做“统计信心“ ，无论你的测试结果明显的。如果你只有少数转换或游客，它都无法确定最终的结果。大多数A / B测试工具都有报告统计，但如果你是手动测试，你可以使用 在线计算器。
• 不要让常客惊讶。如果你正在测试网站的一部分。包括新访客和常客，不要使他们觉得震惊。尤其不要因为哪些可能不会最终实施变化。
• 不要让你的直觉推翻了测试结果。在A / B测试的结果往往是令人惊讶的或直观的。在一个绿色为主题的网站，一个明显的红色按钮有可能成为赢家。即使红色按钮不容易吸引注意。您要测试的目标是一个更好的转换率，而不是美学，所以在得到测试借过钱不要拒绝任何尝试。

需要做的

• 知道运行测试多久。结束太早，可能会使你花了时间但是没有得到有意义的结果。结束太晚也不好，因为效果不佳的页面可能影响你的转化和业绩。使用一个计算器，来确定测试多久以后来结束它。
• 将相同的页面呈献给同一个访客。您的工具应该有一个记忆访问者已经看到的页面的功能。这样可以防止向同一用户显示一不同的价格或不同的促销优惠。
• 让您的A / B测试在整个网站保持一致。如果你正在测试的登录按钮在多个地点出现，然后一个访问者应在所有的地方看到同样的变化。在页面1显示一个样子，在页面2显示两外一个样子，会使试验结果被干扰。
• 做很多的A / B测试。让我们面对现实吧：你的第一个A / B测试可能会无效。但是不要绝望。一个A / B测试只能有三个结果：没有结果，不好的结果和好的结果。优化转换率的关键是要做大量的A / B测试，把所有的好的结果拼接起来，最终推动业绩。

经典A/B测试案例研究

这里有一些如何进行A/B测试的案例研究。

Writing Decisions: Headline Tests on the Highrise Sign-Up Page 37Signals测试他们的价格页面的标题。最终发现， “30-Day Free Trial on All Accounts “比原来的“Start a Highrise Account. “多产生30 ％以上的订单。

“You Should Follow Me on Twitter Here” (Dustin Curtis) 这是一个用来测试召唤用户在Twitter上关注自己的试验。. Dustin 发现提示文字是“You should follow me on Twitter here” 的效果是“I’m on Twitter.” 173%

Human Photos Double Conversion Rates 从两个不同的A / B测试将在网站上增加转换率的人的照片：一个令人令人惊讶的结论，A/B测试两张图片，将真人照片放在网站上会获得一倍的转化。研究说明，我们潜意识被照片吸引了。

Google Website Optimizer Case Study: Daily Burn, 20%+ Improvement (Tim Ferriss) 一个将用户选择减少的变化使转化提高了20%，最终的版本在细节和文字上更易吸引目光。

Two Magical Words Increased Conversion Rate by 28% “It’s free” 这个单词增加了注册按钮点击次数的28%, 测试结果表明，在行动召唤上一些很小的变化会带来令人惊讶的结果。

Changing the Sign-Up Button from Green to Red 依靠A / B测试， CareLogger把注册按钮从绿色修改为红色增加了34％转换率！

Single page vs. multi-step checkout 如果你有一个在线商店，很常见的就是支付流程。这个A / B测试发现，多个支付流程比单个支付流程完成的销售更好。

“Mad Libs” style form increases conversion 25-40% 打败传统的智慧，此A / B测试发现一段风格形式输入字段比传统形式的布局更好。

Complete redesign of product page increased sales by 20% 一个软件产品的公司重新设计他们的产品页给它一个现代的外观和增加信任模块。最终结果：他们成功地增加20 ％的总销售额。本案例研究证明了设计对销售的影响。

Marketing Experiments response capture case study – triple digit increase in conversions 通过优化邮件地址获取提高了258 ％。重点是消除所有的干扰，并要求游客只需提供电子邮件地址。使用亚马逊礼品卡让他/她的完成个人资料。

A/B测试工具

有许多侧重点，价位和功能不同的A / B测试工具，这里是一些：

• Google Website Optimizer
  搜索巨头提供的免费A/B测试工具。一个很好的入门级工具，但是没有一些先进的功能。
• A/Bingo and Vanity
  基于Ruby on Rails开发的服务器组件。需要编程和代码集成。
• Visual Website Optimizer
  一个易于使用的A / B测试工具，包含一些先进的功能，如所见即所得的编辑器，单击地图，访问者分割和标签等。
• Unbounce and Performable
  集成着陆页设计的A / B测试工具。
• Vertster, SiteSpect, Webtrends Optimize and Omniture’s Test&Target
  企业级测试工具。

一些深入研究的A/B测试资料

如果你已经读到这里，那么A / B测试大概已经激起你的兴趣。在这里，有一些非常好的A/B测试资源。

寻找你下一个A/B测试的灵感

• Which Test Won?
  一个猜测那种情况会最终胜利的游戏。
• 101 A/B Testing Tips
  大量的A/B测试技巧和方法。
• ABtests.com
  一个可以分享和阅读A/B测试结果的地方。
• A/B Ideafox
  搜索引擎的A / B和多变量的案例研究。

一些介绍性文章

• Effective A/B Testing
  By Ben Tilly.
• Practical Guide to Controlled Experiments on the Web (PDF)
  From Microsoft Research.
• Introduction to A/B Testing
  From the 20bits blog

A/B测试中的数学

• Statistics for A/B Testing
  From the 20bits blog.
• How Not to Do A/B Testing
• What You Should Know About the Mathematics of A/B Testing
  From my own blog.
• Easy Statistics for AdWords A/B Testing, and Hamsters
• Statistical Significance and Other A/B Test Pitfalls

原文地址：http://www.smashingmagazine.com/2010/06/24/the-ultimate-guide-to-a-b-testing/
转载自：http://ucdchina.com/snap/7203

参数很多,一般我们用 -c 和 -n 参数就可以了. 例如:

./ab -c 1000 -n 1000 http://10.88.15.77/test.php

这个表示同时处理1000个请求并运行1000次index.php文件.
#ab -c 1000 -n 1000 http://10.88.15.77/test.php

Benchmarking 10.88.15.77 (be patient)

Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software:        Apache/2.2.8
//平台apache 版本2.2.8
Server Hostname:        10.88.15.77
//服务器主机名
Server Port:            80
//服务器端口

Document Path:          /test.php

//测试的页面文档
Document Length:        1018 bytes
//文档大小

Concurrency Level:      1000
//并发数
Time taken for tests:   8.188731 seconds
//整个测试持续的时间
Complete requests:      1000
//完成的请求数量
Failed requests:        0
//失败的请求数量
Write errors:           0

Total transferred:      1361581 bytes
//整个场景中的网络传输量
HTML transferred:       1055666 bytes
//整个场景中的HTML内容传输量
Requests per second:    122.12 [#/sec] (mean)
//大家最关心的指标之一，相当于 LR 中的 每秒事务数 ，后面括号中的 mean 表示这是一个平均值
Time per request:       8188.731 [ms] (mean)
//大家最关心的指标之二，相当于 LR 中的 平均事务响应时间 ，后面括号中的 mean 表示这是一个平均值
Time per request:       8.189 [ms] (mean, across all concurrent requests)
//每个请求实际运行时间的平均值
Transfer rate:          162.30 [Kbytes/sec] received
//平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms)
              min mean[+/-sd] median   max
Connect:        4 646 1078.7     89    3291
Processing:   165 992 493.1    938    4712
Waiting:      118 934 480.6    882    4554
Total:        813 1638 1338.9   1093    7785
//网络上消耗的时间的分解，各项数据的具体算法还不是很清楚

Percentage of the requests served within a certain time (ms)
50%   1093
66%   1247
75%   1373
80%   1493
90%   4061
95%   4398
98%   5608
99%   7368
100%   7785 (longest request)
//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于1093 毫秒，60％ 的用户响应时间小于1247 毫秒，最大的响应时间小于7785 毫秒

      由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数
转自：http://blog.sina.com.cn/s/blog_3c9872d00100dbox.html

• blocking I/O

• nonblocking I/O

• I/O multiplexing (select and poll)

• signal driven I/O (SIGIO)

• asynchronous I/O (the POSIX aio_functions)

blocking I/O
这个不用多解释吧，阻塞套接字。下图是它调用过程的图示：

重点解释下上图，下面例子都会讲到。首先application调用 recvfrom()转入kernel，注意kernel有2个过程，wait for data和copy data from kernel to user。直到最后copy complete后，recvfrom()才返回。此过程一直是阻塞的。

nonblocking I/O：
与blocking I/O对立的，非阻塞套接字，调用过程图如下：

可以看见，如果直接操作它，那就是个轮询。。直到内核缓冲区有数据。

I/O multiplexing (select and poll)
最常见的I/O复用模型，select。

select先阻塞，有活动套接字才返回。与blocking I/O相比，select会有两次系统调用，但是select能处理多个套接字。

signal driven I/O (SIGIO)
只有UNIX系统支持，感兴趣的课查阅相关资料

与I/O multiplexing (select and poll)相比，它的优势是，免去了select的阻塞与轮询，当有活跃套接字时，由注册的handler处理。

asynchronous I/O (the POSIX aio_functions)
很少有*nix系统支持，windows的IOCP则是此模型

完全异步的I/O复用机制，因为纵观上面其它四种模型，至少都会在由kernel copy data to appliction时阻塞。而该模型是当copy完成后才通知application，可见是纯异步的。好像只有windows的完成端口是这个模型，效率也很出色。

下面是以上五种模型的比较

可以看出，越往后，阻塞越少，理论上效率也是最优。

=====================分割线==================================

5种模型的比较比较清晰了，剩下的就是把select,epoll,iocp,kqueue按号入座那就OK了。

select和iocp分别对应第3种与第5种模型，那么epoll与kqueue呢？其实也于select属于同一种模型，只是更高级一些，可以看作有了第4种模型的某些特性，如callback机制。

那么，为什么epoll,kqueue比select高级？

答案是，他们无轮询。因为他们用callback取代了。想想看，当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。

windows or *nix （IOCP or kqueue/epoll）？

诚然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系统，但是由于其系统本身的局限性，大型服务器还是在UNIX下。而且正如上面所述，kqueue/epoll 与 IOCP相比，就是多了一层从内核copy数据到应用层的阻塞，从而不能算作asynchronous I/O类。但是，这层小小的阻塞无足轻重，kqueue与epoll已经做得很优秀了。

提供一致的接口，IO Design Patterns

实际上，不管是哪种模型，都可以抽象一层出来，提供一致的接口，广为人知的有ACE,Libevent这些，他们都是跨平台的，而且他们自动选择最优的I/O复用机制，用户只需调用接口即可。说到这里又得说说2个设计模式，Reactor and Proactor。有一篇经典文章http://www.artima.com/articles/io_design_patterns.html值得阅读，Libevent是Reactor模型，ACE提供Proactor模型。实际都是对各种I/O复用机制的封装。

Java nio包是什么I/O机制？

我曾天真的认为java nio封装的是IOCP。。现在可以确定，目前的java本质是select()模型，可以检查/jre/bin/nio.dll得知。至于java服务器为什么效率还不错。。我也不得而知，可能是设计得比较好吧。。-_-。

=====================分割线==================================

总结一些重点：

1. 只有IOCP是asynchronous I/O，其他机制或多或少都会有一点阻塞。
2. select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善
3. epoll, kqueue是Reacor模式，IOCP是Proactor模式。
4. java nio包是select模型。。

转载自：http://blog.csdn.net/shallwake/article/details/5265287

Heap = {Old + NEW = { Eden , from, to } }
具体可查看javavisualvm

JVM内存模型中分两大块，一块是 NEW Generation, 另一块是Old Generation. 在New Generation中，有一个叫Eden的空间，主要是用来存放新生的对象，还有两个Survivor Spaces（from,to）, 它们用来存放每次垃圾回收后存活下来的对象。在Old Generation中，主要存放应用程序中生命周期长的内存对象，还有个Permanent Generation，主要用来放JVM自己的反射对象，比如类对象和方法对象等。
 

垃圾回收描述：

在New Generation块中，垃圾回收一般用Copying的算法，速度快。每次GC的时候，存活下来的对象首先由Eden拷贝到某个Survivor Space, 当Survivor Space空间满了后, 剩下的live对象就被直接拷贝到Old Generation中去。因此，每次GC后，Eden内存块会被清空。在Old Generation块中，垃圾回收一般用mark-compact的算法，速度慢些，但减少内存要求.
垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收OLD段中的垃圾；1级或以上为部分垃圾回收，只会回收NEW中的垃圾，内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。

当一个URL被访问时，内存申请过程如下：
A. JVM会试图为相关Java对象在Eden中初始化一块内存区域
B. 当Eden空间足够时，内存申请结束。否则到下一步
C. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）, 释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区
D. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区
E. 当OLD区空间不够时，JVM会在OLD区进行完全的垃圾收集（0级）
F. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”

JVM调优建议:

ms/mx：定义YOUNG+OLD段的总尺寸，ms为JVM启动时YOUNG+OLD的内存大小；mx为最大可占用的YOUNG+OLD内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。
NewSize/MaxNewSize：定义YOUNG段的尺寸，NewSize为JVM启动时YOUNG的内存大小；MaxNewSize为最大可占用的YOUNG内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。
PermSize/MaxPermSize：定义Perm段的尺寸，PermSize为JVM启动时Perm的内存大小；MaxPermSize为最大可占用的Perm内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。
SurvivorRatio：设置Survivor空间和Eden空间的比例

内存溢出的可能性

1. OLD段溢出
这种内存溢出是最常见的情况之一，产生的原因可能是：
1) 设置的内存参数过小(ms/mx, NewSize/MaxNewSize)
2) 程序问题
单个程序持续进行消耗内存的处理，如循环几千次的字符串处理，对字符串处理应建议使用StringBuffer。此时不会报内存溢出错，却会使系统持续垃圾收集，无法处理其它请求，相关问题程序可通过Thread Dump获取（见系统问题诊断一章）单个程序所申请内存过大，有的程序会申请几十乃至几百兆内存，此时JVM也会因无法申请到资源而出现内存溢出，对此首先要找到相关功能，然后交予程序员修改，要找到相关程序，必须在Apache日志中寻找。
当Java对象使用完毕后，其所引用的对象却没有销毁，使得JVM认为他还是活跃的对象而不进行回收，这样累计占用了大量内存而无法释放。由于目前市面上还没有对系统影响小的内存分析工具，故此时只能和程序员一起定位。

2. Perm段溢出
通常由于Perm段装载了大量的Servlet类而导致溢出，目前的解决办法：
1) 将PermSize扩大，一般256M能够满足要求
2) 若别无选择，则只能将servlet的路径加到CLASSPATH中，但一般不建议这么处理

3. C Heap溢出
系统对C Heap没有限制，故C Heap发生问题时，Java进程所占内存会持续增长，直到占用所有可用系统内存

其他：

JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。

为什么一些程序频繁发生GC？有如下原因：
l         程序内调用了System.gc()或Runtime.gc()。
l         一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。
l         Java的Heap太小，一般默认的Heap值都很小。
l         频繁实例化对象，Release对象。此时尽量保存并重用对象，例如使用StringBuffer()和String()。
如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间。
经验之谈：
1．Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC，最好让-Xmn值约等于-Xmx的1/3[2]。
2．一个GUI程序最好是每10到20秒间运行一次GC，每次在半秒之内完成[2]。
注意：
1．增加Heap的大小虽然会降低GC的频率，但也增加了每次GC的时间。并且GC运行时，所有的用户线程将暂停，也就是GC期间，Java应用程序不做任何工作。
2．Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，因为Java为其他任务分配内存，例如每个线程的Stack等。
2．Stack的设定
每个线程都有他自己的Stack。

-Xss 每个线程的Stack大小

Stack的大小限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。
3．硬件环境
硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。
如果你的程序需要频繁创建很多transient对象，会导致JVM频繁GC。这种情况你可以增加机器的内存，来减少Swap空间的使用[2]。
4．4种GC
第一种为单线程GC，也是默认的GC。，该GC适用于单CPU机器。
第二种为Throughput GC，是多线程的GC，适用于多CPU，使用大量线程的程序。第二种GC与第一种GC相似，不同在于GC在收集Young区是多线程的，但在Old区和第一种一样，仍然采用单线程。-XX:+UseParallelGC参数启动该GC。
第三种为Concurrent Low Pause GC，类似于第一种，适用于多CPU，并要求缩短因GC造成程序停滞的时间。这种GC可以在Old区的回收同时，运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。
第四种为Incremental Low Pause GC，适用于要求缩短因GC造成程序停滞的时间。这种GC可以在Young区回收的同时，回收一部分Old区对象。-Xincgc参数启动该GC。

(文：包一磊)

AJAX的出现极大的改变了Web应用客户端的操作模式，它使的用户可以在全心工作时不必频繁的忍受那令人厌恶的页面刷新。理论上AJAX技术在很大的程度上可以减少用户操作的等待时间，同时节约网络上的数据流量。而然，实际情况却并不总是这样。用户时常会抱怨用了AJAX的系统响应速度反而降低了。

笔者从事AJAX方面的研发多年，参与开发了目前国内较为成熟的AJAX平台-dorado。根据笔者的经验，导致这种结果的根本原因并不在AJAX。很多时候系统响应速度的降低都是由不够合理的界面设计和不够高效的编程习惯造成的。下面我们就来分析几个AJAX开发过程中需要时刻注意的环节。

n 合理的使用客户端编程和远程过程调用。

客户端的编程主要都是基于JavaScript的。而JavaScript是一种解释型的编程语言，它的运行效率相对于Java等都要稍逊一筹。同时JavaScript又是运行在浏览器这样一个严格受限的环境当中。因此开发人员对于哪些逻辑可以在客户端执行应该有一个清醒的认识。

在实际的应用中究竟应该怎样使用客户端编程，这依赖于开发人员的经验判断。这里很多问题是只可意会的。由于篇幅有限，在这里我们大致归纳出下面这几个注意事项：

u 尽可能避免频繁的使用远程过程调用，例如避免在循环体中使用远程过程调用。

u 如果可能的话尽可能使用AJAX方式的远程过程调用（异步方式的远程过程调用）。

u 避免将重量级的数据操作放置在客户端。例如：大批量的数据复制操作、需要通过大量的数据遍历完成的计算等。

n 改进对DOM对象的操作方式。

客户端的编程中，对DOM对象的操作往往是最容易占用CPU时间的。而对于DOM对象的操作，不同的编程方法之间的性能差异又往往是非常大的。

以下是三段运行结果完全相同的代码，它们的作用是在网页中创建一个10x1000的表格。然而它们的运行速度却有着天壤之别。

这里的“测试代码1”和“测试代码2”之间的差别在于在创建表格单元时使用了不同的API方法。而“测试代码2”和“测试代码3”之间的差别在于处理顺序的略微不同。

“测试代码1”和“测试代码2”之间如此大的性能差别我们无从分析，目前所知的是insertRow和insertCell是DHTML中表格特有的API，createElement和appendChild是W3C DOM的原生API。而前者应该是对后者的封装。不过，我们并不能因此而得出结论认为DOM的原生API总是优于对象特有的API。建议大家在需要频繁调用某一API时，对其性能表现做一些基本的测试。

“测试代码2”和“测试代码3”之间的性能差异主要来自于他们的构建顺序不同。“测试代码2”的做法是首先创建最外层的<TABLE>对象，然后再在循环中依次创建<TR>和<TD>。而“测试代码3”的做法是首先在内存中由内到外的构建好整个表格，最后再将它添加到网页中。这样做的目的是尽可能的减少浏览器重新计算页面布局的次数。每当我们将一个对象添加到网页中时，浏览器都会尝试对页面中的控件的布局进行重新计算。所以，如果我们能够首先在内存中将整个要构造的对象全部创建好，然后再一次性的添加到网页中。那么，浏览器将只会做一次布局的重计算。总结为一句话那就是越晚执行appendChild越好。有时为了提高运行效率，我们甚至可以考虑先使用removeChild将已存在的控件从页面中移除，然后构造完成后再重新将其放置回页面当中。

n 提高字符串累加的速度

在使用AJAX提交信息时，我可能常常需要拼装一些比较大的字符串通过XmlHttp来完成POST提交。尽管提交这样大的信息的做法看起来并不优雅，但有时我们可能不得不面对这样的需求。那么JavaScript中对字符串的累加速度如何呢？我们先来做下面的这个实验。累加一个长度为30000的字符串。

这段代码耗时14.325秒，结果并不理想。现在我们将代码改为如下的形式：

这段代码耗时0.359秒！同样的结果，我们做的只是首先拼装一些较小的字符串然后再组装成更大的字符串。这种做法可以有效的在字符串拼装的后期减小内存复制的数据量。知道了这一原理之后我们还可以把上面的代码进一步拆散以后进行测试。下面的代码仅耗时0.140秒。

不过，上面这种做法也许并不是最好的！如果我们需要提交的信息是XML格式的（其实绝大多数情况下，我们都可以设法将要提交的信息组装成XML格式），我们还能找到更高效更优雅的方法—利用DOM对象为我们组装字符串。下面这段代买组装一个长度为950015的字符串仅须耗时0.890秒。

n 避免DOM对象的内存泄漏。

关于IE中DOM对象的内存泄露是一个常常被开发人员忽略的问题。然而它带来的后果却是非常严重的！它会导致IE的内存占用量持续上升，并且浏览器的整体运行速度明显下降。对于一些泄露比较严重的网页，甚至只要刷新几次，运行速度就会降低一倍。

比较常见的内存泄漏的模型有“循环引用模型”、“闭包函数模型”和“DOM插入顺序模型”,对于前两种泄漏模型，我们都可以通过在网页析构时解除引用的方式来避免。而对于“DOM插入顺序模型”则需要通过改变一些惯有的编程习惯的方式来避免。

有关内存泄漏的模型的更多介绍可以通过Google很快的查到，本文不做过多的阐述。不过，这里我向您推荐一个可用于查找和分析网页内存泄露的小工具—Drip，目前的较新版本是0.5，下载地址是http://outofhanwell.com/ieleak/index.php

n 复杂页面的分段装载和初始化

对系统当中某些确实比较复杂而又不便使用IFrame的界面，我们可以对其实施分段装载。例如对于多页标签的界面，我们可以首先下载和初始化多页标签的默认页，然后利用AJAH（asynchronous JavaScript and HTML）技术来异步的装载其他标签页中的内容。这样就能保证界面可以在第一时间首先展现给用户。把整个复杂界面的装载过程分散到用户的操作过程当中。

n 利用GZIP压缩网络流量。

除了上面提到的这些代码级的改良之外，我们还可以利用GZIP来有效的降低网络流量。目前常见的主流浏览器已经全部支持GZIP算法，我们往往只需要编写少量的代码就可以支持GZIP了。例如在J2EE中我们可以在Filter中通过下面的代码来判断客户端浏览器是否支持GZIP算法，然后根据需要利用java.util.zip.GZIPOutputStream来实现GZIP的输出。

一般而言，GZIP对于HTML、JSP的压缩比可以达到80%左右，而它造成的服务端和客户端的性能损耗几乎是可以忽略的。结合其他因素，支持GZIP的网站有可能为我们节约50%的网络流量。因此GZIP的使用可以为那些网络环境不是特别好的应用带来显著的性能提升。使用Http的监视工具Fiddler可以方便的检测出网页在使用GZIP前后的通讯数据量。Fiddler的下载地址是http://www.fiddlertool.com/fiddler/

关于Web应用的性能优化其实是一个非常大的话题。本文由于篇幅有限，只能涉及其中的几个细节，并且也无法将这些细节的优化方式全面的展现给大家。期望本文能够引起大家对Web应用尤其是客户端性能优化的充分重视。毕竟服务端编程技巧已为大家熟知多年，在服务端挖掘性能的潜力已经不大了。而在客户端的方法改进往往能够得到令人惊奇的性能提升。

作者： KeeKim Heng, Google Web Developer

在我们开发互联网富应用（RIA）时，我们经常写一些javascript脚本来修改或者增加页面元素，这些工作最终是DOM——或者说文档对象模型——来完成的，而我们的实现方式会影响到应用的响应速度。

DOM操作会导致浏览器重解析(reflow)，这是浏览器的一个决定页面元素如何展现的计算过程。直接修改DOM，修改元素的CSS样式，修改浏览器的窗口大小，都会触发重解析。读取元素的布局属性比如offsetHeithe或者offsetWidth也会触发重解析。重解析需要花费计算时间，因此重解析触发的越少，应用就会越快。

DOM操作通常要不就是修改已经存在的页面上的元素，要不就是创建新的页面元素。下面的4种优化方案覆盖了修改和创建DOM节点两种方式，帮助你减少触发浏览器重解析的次数。

方案一：通过CSS类名切换来修改DOM

这个方案让我们可以一次性修改一个元素和它的子元素的多个样式属性而只触发一次重解析。

需求：

（emu注：原文作者写到这里的时候脑子显然短路了一下，把后面的Out-of-the-flow DOM Manipulation模式要解决的问题给摆到这里来了，不过从示范代码中很容易明白作者真正想描述的问题，因此emu就不照翻原文了）

我们现在需要写一个函数来修改一个超链接的几个样式规则。要实现很简单，把这几个规则对应的属性逐一改了就好了。但是带来的问题是，每修改一个样式属性，都会导致一次页面的重解析。

view plaincopy to clipboardprint?
function selectAnchor(element) {  
  element.style.fontWeight = 'bold';  
  element.style.textDecoration = 'none';  
  element.style.color = '#000';  
} 
function selectAnchor(element) {
  element.style.fontWeight = 'bold';
  element.style.textDecoration = 'none';
  element.style.color = '#000';
}

解决方案

要解决这个问题，我们可以先创建一个样式名，并且把要修改的样式规则都放到这个类名上，然后我们给超链接添加上这个新类名，就可以实现添加几个样式规则而只触发一次重解析了。这个模式还有个好处是也实现了表现和逻辑相分离。

view plaincopy to clipboardprint?
.selectedAnchor {  
  font-weight: bold;  
  text-decoration: none;  
  color: #000;  
}  
 
function selectAnchor(element) {  
  element.className = 'selectedAnchor';  
} 
.selectedAnchor {
  font-weight: bold;
  text-decoration: none;
  color: #000;
}

function selectAnchor(element) {
  element.className = 'selectedAnchor';
}

 方案二：在非渲染区修改DOM

（emu注：作者在这里再次脑子短路，把DocumentFragment DOM Generation模式的介绍提前到这里来了，emu只好再次发挥一下）
上一个方案解决的是修改一个超链接的问题，当一次需要对很多个超链接进行相同修改的时候，这个方案就可以大显身手了。

需求

需求是这样的，我们要写一个函数来修改一个指定元素的子元素中所有的超链接的样式名（className）属性。要实现很简单，我们可以通过遍历每个超链接并且修改它们的样式名来完成任务。但是带来的问题就是，每修改一个超链接都会导致一次重解析。

view plaincopy to clipboardprint?
function updateAllAnchors(element, anchorClass) {  
  var anchors = element.getElementsByTagName('a');  
  for (var i = 0, length = anchors.length; i < length; i ++) {  
    anchors[i].className = anchorClass;  
  }  
} 
function updateAllAnchors(element, anchorClass) {
  var anchors = element.getElementsByTagName('a');
  for (var i = 0, length = anchors.length; i < length; i ++) {
    anchors[i].className = anchorClass;
  }
}
 

解决方案

要解决这个问题，我们可以把被修改的指定元素从DOM里面移除，再修改所有的超链接，然后在把这个元素插入回到它原来的位置上。为了完成这个复杂的操作，我们可以先写一个可重用的函数，它不但移除了这个DOM节点，还返回了一个把元素插回到原来的位置的函数。

view plaincopy to clipboardprint?
/** 
 * Remove an element and provide a function that inserts it into its original position 
 * @param element {Element} The element to be temporarily removed 
 * @return {Function} A function that inserts the element into its original position 
 **/ 
function removeToInsertLater(element) {  
  var parentNode = element.parentNode;  
  var nextSibling = element.nextSibling;  
  parentNode.removeChild(element);  
  return function() {  
    if (nextSibling) {  
      parentNode.insertBefore(element, nextSibling);  
    } else {  
      parentNode.appendChild(element);  
    }  
  };  
} 
/**
 * Remove an element and provide a function that inserts it into its original position
 * @param element {Element} The element to be temporarily removed
 * @return {Function} A function that inserts the element into its original position
 **/
function removeToInsertLater(element) {
  var parentNode = element.parentNode;
  var nextSibling = element.nextSibling;
  parentNode.removeChild(element);
  return function() {
    if (nextSibling) {
      parentNode.insertBefore(element, nextSibling);
    } else {
      parentNode.appendChild(element);
    }
  };
}

有了上面这个函数，现在我们就可以在一个不需要解析渲染的元素上面修改那些超链接了。这样只在移除和插入元素的时候各触发一次重解析。

view plaincopy to clipboardprint?
function updateAllAnchors(element, anchorClass) {  
  var insertFunction = removeToInsertLater(element);  
  var anchors = element.getElementsByTagName('a');  
  for (var i = 0, length = anchors.length; i < length; i ++) {  
    anchors[i].className = anchorClass;  
  }  
  insertFunction();  
} 
function updateAllAnchors(element, anchorClass) {
  var insertFunction = removeToInsertLater(element);
  var anchors = element.getElementsByTagName('a');
  for (var i = 0, length = anchors.length; i < length; i ++) {
    anchors[i].className = anchorClass;
  }
  insertFunction();
}
 

方案三：一次性的DOM元素生成

这个方案让我们创建一个元素的过程只触发一次重解析。在创建完元素以后，先进行所有需要的修改，最后才把它插入到DOM里面去就可以了

需求

需求是这样的，实现一个函数，往一个指定的父元素上插入一个超链接元素。这个函数要同时可以设置这个超链接的显示文字和样式类。我们可以这样做：创建元素，插入到DOM里面，然后设置相应的属性。这就要触发3次重解析。

view plaincopy to clipboardprint?
function addAnchor(parentElement, anchorText, anchorClass) {  
  var element = document.createElement('a');  
  parentElement.appendChild(element);  
  element.innerHTML = anchorText;  
  element.className = anchorClass;  
} 
function addAnchor(parentElement, anchorText, anchorClass) {
  var element = document.createElement('a');
  parentElement.appendChild(element);
  element.innerHTML = anchorText;
  element.className = anchorClass;
}
 

解决方案

很简单，我们只要把插入元素这个操作放到最后做，就可以只进行一次重解析了。

view plaincopy to clipboardprint?
function addAnchor(parentElement, anchorText, anchorClass) {  
  var element = document.createElement('a');  
  element.innerHTML = anchorText;  
  element.className = anchorClass;  
  parentElement.appendChild(element);  
} 
function addAnchor(parentElement, anchorText, anchorClass) {
  var element = document.createElement('a');
  element.innerHTML = anchorText;
  element.className = anchorClass;
  parentElement.appendChild(element);
}

不过，要是我们想要插入很多个超链接到一个元素里面的话，那么这个做法还是有问题：每插入一个超链接还是要触发一次重解析。下一个方案可以解决这个问题。

方案四：通过文档片段对象（DocumentFragment）创建一组元素

这个方案允许我们创建并插入很多个元素而只触发一次重解析。要实现这点需要用到所谓的文档片段对象（DocumentFragment）。我们先在DOM之外创建一个文档片段对象（这样它也就不需要解析和渲染），然后我们在文档片段对象中创建很多个元素，最后我们把这个文档片段对象中所有的元素一次性放到DOM里面去，只触发一次重解析。

需求

我们要写一个函数，往一个指定的元素上面增加10个超链接。如果我们简单的直接插入10个超链接到元素上面，就会触发10次重解析。

view plaincopy to clipboardprint?
function addAnchors(element) {  
  var anchor;  
  for (var i = 0; i < 10; i ++) {  
    anchor = document.createElement('a');  
    anchor.innerHTML = 'test';  
    element.appendChild(anchor);  
  }  
} 
function addAnchors(element) {
  var anchor;
  for (var i = 0; i < 10; i ++) {
    anchor = document.createElement('a');
    anchor.innerHTML = 'test';
    element.appendChild(anchor);
  }
}

解决方案

要解决这个问题，我们要先创建一个文档片段对象，然后把每个新创建的超链接都插入到它里面去。当我们把文档片段对象用appendChild命令插入到指定的节点时，这个文档片段对象的所有子节点就一起被插入到指定的元素里面，而且只需要触发一次重解析。

view plaincopy to clipboardprint?
function addAnchors(element) {  
  var anchor, fragment = document.createDocumentFragment();  
  for (var i = 0; i < 10; i ++) {  
    anchor = document.createElement('a');  
    anchor.innerHTML = 'test';  
    fragment.appendChild(anchor);  
  }  
  element.appendChild(fragment);  
} 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/emu/archive/2010/03/01/5334583.aspx

    在生产环境中tomcat内存设置不好很容易出现内存溢出。造成内存原因是不一样的，当然处理方式也不一样。

    这里根据平时遇到的情况和相关资料进行一个总结。常见的一般会有下面三种情况：

    1.OutOfMemoryError： Java heap space

    2.OutOfMemoryError： PermGen space

    3.OutOfMemoryError： unable to create new native thread.

    Tomcat内存溢出解决方案

    对于前两种情况，在应用本身没有内存泄露的情况下可以用设置tomcat jvm参数来解决。（-Xms -Xmx -XX：PermSize  -XX：MaxPermSize）

    最后一种可能需要调整操作系统和tomcat jvm参数同时调整才能达到目的。

    第一种：是堆溢出。

    在JVM中如果98％的时间是用于GC且可用的 Heap size 不足2％的时候将抛出此异常信息。

    没有内存泄露的情况下，调整-Xms -Xmx参数可以解决。

    -Xms：初始堆大小

    -Xmx：最大堆大小

    但堆的大小受下面三方面影响：

    1.相关操作系统的数据模型（32-bt还是64-bit）限制；（32位系统下，一般限制在1.5G~2G；我在2003 server 系统下（物理内存：4G和6G，jdk：1.6）测试 1612M，64为操作系统对内存无限制。）

    2.系统的可用虚拟内存限制；

    3.系统的可用物理内存限制。

    堆的大小可以使用 java -Xmx***M  version 命令来测试 。支持的话会出现jdk的版本号，不支持会报错。

    -Xms -Xmx一般配置成一样比较好比如set JAVA_OPTS= -Xms1024m -Xmx1024m

    第二种：永久保存区域溢出

    PermGen space的全称是Permanent Generation space，是指内存的永久保存区域。这一部分用于存放Class和Meta的信息，Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同，GC（Garbage Collection）不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话，就很可能出现PermGen space错误。这种错误常见在web服务器 对JSP进行pre compile的时候。但目前的hibernate和spring项目中也很容易出现这样的问题。http://www.javaeye.com/topic/80620 ?page=1 的帖子有讨论的这个问题。可能是由于这些框架会动态class，而且jvm的gc是不会清理PemGen space的，导致内存溢出。

    这一个一般是加大-XX：PermSize  -XX：MaxPermSize 来解决问题。

    -XX：PermSize 永久保存区域初始大小

    -XX：PermSize 永久保存区域初始最大值

    这一般结合第一条使用，比如 set JAVA_OPTS= -Xms1024m -Xmx1024m  -XX：PermSize=128M -XX：PermSize=256M

    有一点需要注意：java -Xmx***M  version 命令来测试的最大堆内存是 -Xmx与 -XX：PermSize的 和 比如系统支持最大的jvm堆大小事1.5G，那  -Xmx1024m  -XX：PermSize=768M 是无法运行的。

    第三种：无法创建新的线程。

    这种现象比较少见，也比较奇怪，主要是和jvm与系统内存的比例有关。

    这种怪事是因为JVM已经被系统分配了大量的内存（比如1.5G），并且它至少要占用可用内存的一半。有人发现，在线程个数很多的情况下，你分配给JVM 的内存越多，那么，上述错误发生的可能性就越大。

    产生这种现象的原因如下（从这个blog中了解到原因：http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html ）：

    每一个32位的进程最多可以使用2G的可用内存，因为另外2G被操作系统保留。这里假设使用1.5G给JVM，那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载，那么真正剩下的也许只有400M，现在关键的地方出现了：当你使用Java 创建一个线程，在JVM的内存里也会创建一个Thread对象，但是同时也会在操作系统里创建一个真正的物理线程（参考JVM规范），操作系统会在余下的400兆内存里创建这个物理线程，而不是在JVM的1500M的内存堆里创建。在jdk1.4里头，默认的栈大小是256KB，但是在jdk1.5里头，默认的栈大小为1M每线程，因此，在余下400M的可用内存里边我们最多也只能创建400个可用线程。

    这样结论就出来了，要想创建更多的线程，你必须减少分配给JVM的最大内存。还有一种做法是让JVM宿主在你的JNI代码里边。

    给出一个有关能够创建线程的最大个数的估算公式：

    （MaxProcessMemory - JVMMemory - ReservedOsMemory） / （ThreadStackSize） = Number of threads

    对于jdk1.5而言，假设操作系统保留120M内存：

    1.5GB JVM： （2GB-1.5Gb-120MB）/（1MB） = ~380 threads

    1.0GB JVM： （2GB-1.0Gb-120MB）/（1MB） = ~880 threads

    在2000/XP/2003的boot.ini里头有一个启动选项，好像是：/PAE /3G ，可以让用户进程最大内存扩充至3G，这时操作系统只能占用最多1G的虚存。那样应该可以让JVM创建更多的线程。

    因此这种情况需要结合操作系统进行相关调整。

    因此：我们需要结合不同情况对tomcat内存分配进行不同的诊断才能从根本上解决问题。

    以上就是针对Tomcat内存溢出的几种解决方案。本文来自George的博客：《tomcat内存溢出总结》

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Senton/archive/2010/07/01/5707446.aspx

1 - Tomcat Server的组成部分
1.1 - Server

A Server element represents the entire Catalina servlet container. (Singleton)

1.2 - Service

A Service element represents the combination of one or more Connector components that share a single Engine
Service是这样一个集合：它由一个或者多个Connector组成，以及一个Engine，负责处理所有Connector所获得的客户请求

1.3 - Connector

一个Connector将在某个指定端口上侦听客户请求，并将获得的请求交给Engine来处理，从Engine处获得回应并返回客户
TOMCAT有两个典型的Connector，一个直接侦听来自browser的http请求，一个侦听来自其它WebServer的请求
Coyote Http/1.1 Connector 在端口8080处侦听来自客户browser的http请求
Coyote JK2 Connector 在端口8009处侦听来自其它WebServer(Apache)的servlet/jsp代理请求

1.4 - Engine

The Engine element represents the entire request processing machinery associated with a particular Service
It receives and processes all requests from one or more Connectors
and returns the completed response to the Connector for ultimate transmission back to the client
Engine下可以配置多个虚拟主机Virtual Host，每个虚拟主机都有一个域名
当Engine获得一个请求时，它把该请求匹配到某个Host上，然后把该请求交给该Host来处理
Engine有一个默认虚拟主机，当请求无法匹配到任何一个Host上的时候，将交给该默认Host来处理

1.5 - Host

代表一个Virtual Host，虚拟主机，每个虚拟主机和某个网络域名Domain Name相匹配
每个虚拟主机下都可以部署(deploy)一个或者多个Web App，每个Web App对应于一个Context，有一个Context path
当Host获得一个请求时，将把该请求匹配到某个Context上，然后把该请求交给该Context来处理
匹配的方法是“最长匹配”，所以一个path==""的Context将成为该Host的默认Context
所有无法和其它Context的路径名匹配的请求都将最终和该默认Context匹配

1.6 - Context

一个Context对应于一个Web Application，一个Web Application由一个或者多个Servlet组成
Context在创建的时候将根据配置文件＄CATALINA_HOME/conf/web.xml和＄WEBAPP_HOME/WEB-INF/web.xml载入Servlet类
当Context获得请求时，将在自己的映射表(mapping table)中寻找相匹配的Servlet类
如果找到，则执行该类，获得请求的回应，并返回

2 - Tomcat Server的结构图
 
3 - 配置文件＄CATALINA_HOME/conf/server.xml的说明
该文件描述了如何启动Tomcat Server

<!----------------------------------------------------------------------------------------------->

<!-- 启动Server
     在端口8005处等待关闭命令
     如果接受到"SHUTDOWN"字符串则关闭服务器
     -->

<Server port="8005" shutdown="SHUTDOWN" debug="0">

  <!-- Listener ???
       目前没有看到这里
       -->

  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" debug="0"/>
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" debug="0"/>

  <!-- Global JNDI resources ???
       目前没有看到这里，先略去
       -->

  <GlobalNamingResources>
    ... ... ... ...
  </GlobalNamingResources>

  <!-- Tomcat的Standalone Service
       Service是一组Connector的集合
       它们共用一个Engine来处理所有Connector收到的请求
       -->

  <Service name="Tomcat-Standalone">

    <!-- Coyote HTTP/1.1 Connector
         className : 该Connector的实现类是org.apache.coyote.tomcat4.CoyoteConnector
         port : 在端口号8080处侦听来自客户browser的HTTP1.1请求
         minProcessors : 该Connector先创建5个线程等待客户请求，每个请求由一个线程负责
         maxProcessors : 当现有的线程不够服务客户请求时，若线程总数不足75个，则创建新线程来处理请求
         acceptCount : 当现有线程已经达到最大数75时，为客户请求排队
                       当队列中请求数超过100时，后来的请求返回Connection refused错误
         redirectport : 当客户请求是https时，把该请求转发到端口8443去
         其它属性略
         -->

    <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
               port="8080"
               minProcessors="5" maxProcessors="75" acceptCount="100"
               enableLookups="true"
               redirectPort="8443"
               debug="0"
               connectionTimeout="20000"
               useURIValidationHack="false"
               disableUploadTimeout="true" />

    <!-- Engine用来处理Connector收到的Http请求
         它将匹配请求和自己的虚拟主机，并把请求转交给对应的Host来处理
         默认虚拟主机是localhost
         -->

    <Engine name="Standalone" defaultHost="localhost" debug="0">
   

      <!-- 日志类，目前没有看到，略去先 -->

      <Logger className="org.apache.catalina.logger.FileLogger" .../>

      <!-- Realm，目前没有看到，略去先 -->

      <Realm className="org.apache.catalina.realm.UserDatabaseRealm" .../>

      <!-- 虚拟主机localhost
           appBase : 该虚拟主机的根目录是webapps/
           它将匹配请求和自己的Context的路径，并把请求转交给对应的Context来处理
           -->

      <Host name="localhost" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="true">
     

        <!-- 日志类，目前没有看到，略去先 -->

        <Logger className="org.apache.catalina.logger.FileLogger" .../>
     

        <!-- Context，对应于一个Web App
             path : 该Context的路径名是""，故该Context是该Host的默认Context
             docBase : 该Context的根目录是webapps/mycontext/
             -->

        <Context path="" docBase="mycontext" debug="0"/>
       

        <!-- 另外一个Context，路径名是/wsota -->

        <Context path="/wsota" docBase="wsotaProject" debug="0"/>
            
       
      </Host>
     
    </Engine>

  </Service>

</Server>

<!----------------------------------------------------------------------------------------------->

4 - Context的部署配置文件web.xml的说明
一个Context对应于一个Web App，每个Web App是由一个或者多个servlet组成的
当一个Web App被初始化的时候，它将用自己的ClassLoader对象载入“部署配置文件web.xml”中定义的每个servlet类
它首先载入在＄CATALINA_HOME/conf/web.xml中部署的servlet类
然后载入在自己的Web App根目录下的WEB-INF/web.xml中部署的servlet类
web.xml文件有两部分：servlet类定义和servlet映射定义
每个被载入的servlet类都有一个名字，且被填入该Context的映射表(mapping table)中，和某种URL PATTERN对应
当该Context获得请求时，将查询mapping table，找到被请求的servlet，并执行以获得请求回应

　　分析一下所有的Context共享的web.xml文件，在其中定义的servlet被所有的Web App载入

<!----------------------------------------------------------------------------------------------->

<web-app>

  <!-- 概述：
       该文件是所有的WEB APP共用的部署配置文件，
       每当一个WEB APP被DEPLOY，该文件都将先被处理，然后才是WEB APP自己的/WEB-INF/web.xml
       -->

  <!--  +-------------------------+  -->
  <!--  |    servlet类定义部分    |  -->
  <!--  +-------------------------+  -->

  <!-- DefaultServlet
       当用户的HTTP请求无法匹配任何一个servlet的时候，该servlet被执行
       URL PATTERN MAPPING : /
       -->

    <servlet>
        <servlet-name>default</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.DefaultServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <init-param>
            <param-name>listings</param-name>
            <param-value>true</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

  <!-- InvokerServlet
       处理一个WEB APP中的匿名servlet
       当一个servlet被编写并编译放入/WEB-INF/classes/中，却没有在/WEB-INF/web.xml中定义的时候
       该servlet被调用，把匿名servlet映射成/servlet/ClassName的形式
       URL PATTERN MAPPING : /servlet/*
       -->

    <servlet>
        <servlet-name>invoker</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.InvokerServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <load-on-startup>2</load-on-startup>
    </servlet>

  <!-- JspServlet
       当请求的是一个JSP页面的时候（*.jsp）该servlet被调用
       它是一个JSP编译器，将请求的JSP页面编译成为servlet再执行
       URL PATTERN MAPPING : *.jsp
       -->

    <servlet>
        <servlet-name>jsp</servlet-name>
        <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
        <init-param>
            <param-name>logVerbosityLevel</param-name>
            <param-value>WARNING</param-value>
        </init-param>
        <load-on-startup>3</load-on-startup>
    </servlet>

  <!--  +---------------------------+  -->
  <!--  |    servlet映射定义部分    |  -->
  <!--  +---------------------------+  -->

   
    <servlet-mapping>
        <servlet-name>default</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>invoker</servlet-name>
        <url-pattern>/servlet/*</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>jsp</servlet-name>
        <url-pattern>*.jsp</url-pattern>
    </servlet-mapping>

  <!--  +------------------------+  -->
  <!--  |    其它部分，略去先    |  -->
  <!--  +------------------------+  -->

    ... ... ... ...

</web-app>

<!----------------------------------------------------------------------------------------------->

5 - Tomcat Server处理一个http请求的过程
假设来自客户的请求为：
http://localhost:8080/wsota/wsota_index.jsp

1) 请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得

2) Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应

3) Engine获得请求localhost/wsota/wsota_index.jsp，匹配它所拥有的所有虚拟主机Host

4) Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机）

5) localhost Host获得请求/wsota/wsota_index.jsp，匹配它所拥有的所有Context

6) Host匹配到路径为/wsota的Context（如果匹配不到就把该请求交给路径名为""的Context去处理）

7) path="/wsota"的Context获得请求/wsota_index.jsp，在它的mapping table中寻找对应的servlet

8) Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类

9) 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法

10)Context把执行完了之后的HttpServletResponse对象返回给Host

11)Host把HttpServletResponse对象返回给Engine

12)Engine把HttpServletResponse对象返回给Connector

13)Connector把HttpServletResponse对象返回给客户browser

-XX

基于 Sun 的 Java 2 Standard Edition（J2SE）5 有生成垃圾回收功能，这允许分隔内存池以包含不同时效的对象。垃圾回收循环根据时效收集与其他对象彼此独立的对象。使用其他参数，您可以单独设置内存池的 大小。为了实现更好的性能，您应该对包含短期存活对象的池的大小进行设置，以使该池中的对象的存活时间不会超过一个垃圾回收循环。新生成的池的大小由 NewSize 和 MaxNewSize 参数确定。

第一次垃圾回收循环中存活下来的对象转移到另一个池中。生还者池的大小由参数 SurvivorRatio 确定。 如果垃圾回收变成了瓶颈，您可以尝试定制生成池设置。要监控垃圾回收统计信息，使用 Tivoli Performance Viewer 中的对象统计信息或 verbose:gc 配置设置。 输入下列值：
-XX:NewSize (lower bound)
-XX:MaxNewSize (upper bound)
-XX:SurvivorRatio=NewRatioSize
-XX:NewSize 320m 此值设大可调大新对象区，减少Full GC次数
-XX:+UseParNewGC ：缩短minor收集的时间 可用来设置并行收集【多CPU】
-XX:+ParallelGCThreads 可用来增加并行度【多CPU】
-XX:+UseParallelGC 设置后可以使用并行清除收集器【多CPU】-Xss：每个线程的Stack大小

-verbose:gc 显示垃圾收集信息
-Xloggc:gc.log 指定垃圾收集日志文件
刚刚了解到的一些参数（待实践测试）
-Xmn：young generation的heap大小，一般设置为Xmx的3、4分之一
-XX:+UseConcMarkSweepGC ：缩短major收集的时间
提示：此选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适

下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M：

java –Xms128m –Xmx128m –XX:NewRatio =3缺省值为：NewSize=2m MaxNewSize=32m SurvivorRatio=2。但是，如果 JVM 的堆大小大于 1GB，则应该使用值：-XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16，或者将堆的总大小的 50% 到 60% 分配给新生成的池。

          举例：永久域默认大小为4m。运行程序时，jvm会调整永久域的大小以满足需要。每次调整时，jvm会对堆进行一次完全的垃圾收集。

使用-XX:MaxPerSize标志来增加永久域的大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当jvm加载类时，永久域中的对象急剧增加，从而使jvm不断调整永久域大小。为了避免 调整，可使用-XX:PerSize标志设置初始值。
   下面把永久域初始值设置成32m，最大值设置成64m。
    java -Xms512m -Xmx512m -Xmn128m -XX:PermSize=32m -XX:MaxPermSize=64m

默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden充 满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助 空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。使用-XX:SurvivorRatio可 控制新域子空间的大小。

目前，我的的开发环境 2G内存，tomcat+eclipse 大型应用程序
java -Xmx1024m -XX:PermSize=512m   基本就ok大部分应用了

我的服务器参数配置:
MY_PARAMS="-Xmn340m -Xss128k -XX:NewSize=640m -XX:MaxNewSize=640m -XX:PermSize=512m -XX:MaxPermSize=512m -XX:+UseParNewGC -Xloggc:gc.log"

本文出处：http://hi.baidu.com/china8jie/blog/item/7c4ac1a2e25a9fa5caefd0d1.html

1. 常见配置汇总
2. 堆设置
   • -Xms :初始堆大小
   • -Xmx :最大堆大小
   • -XX:NewSize=n :设置年轻代大小
   • -XX:NewRatio=n: 设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4
   • -XX:SurvivorRatio=n :年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
   • -XX:MaxPermSize=n :设置持久代大小
3. 收集器设置
   • -XX:+UseSerialGC :设置串行收集器
   • -XX:+UseParallelGC :设置并行收集器
   • -XX:+UseParalledlOldGC :设置并行年老代收集器
   • -XX:+UseConcMarkSweepGC :设置并发收集器
4. 垃圾回收统计信息
   • -XX:+PrintGC
   • -XX:+PrintGCDetails
   • -XX:+PrintGCTimeStamps
   • -Xloggc:filename
5. 并行收集器设置
   • -XX:ParallelGCThreads=n :设置并行收集器收集时使用的CPU数。并行收集线程数。
   • -XX:MaxGCPauseMillis=n :设置并行收集最大暂停时间
   • -XX:GCTimeRatio=n :设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
6. 并发收集器设置
   • -XX:+CMSIncrementalMode :设置为增量模式。适用于单CPU情况。
   • -XX:ParallelGCThreads=n :设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

从8i到10g，Oracle不断进化自己的SQL Tuning智能，一些秘籍级的优化口诀已经失效。
   但我喜欢失效，不用记口诀，操个Toad for Oracle Xpert ，按照大方向舒舒服服的调优才是爱做的事情。

1.Excution Plan
     Excution Plan是最基本的调优概念，不管你的调优吹得如何天花乱堕，结果还是要由Excution plan来显示Oracle 最终用什么索引、按什么顺序连接各表，Full Table Scan还是Access by Rowid Index，瓶颈在什么地方。如果没有它的指导，一切调优都是蒙的。

2.Toad for Oracle Xpert
    用它来调优在真的好舒服。Quest 吞并了Lecco后，将它整合到了Toad 的SQL Tunning里面：最清晰的执行计划显示，自动生成N条等价SQL、给出优化建议，不同SQL执行计划的对比，还有实际执行的逻辑读、物理读数据等等一目了然。

3.索引
   大部分的性能问题其实都是索引应用的问题，Where子句、Order By、Group By 都要用到索引。
   一般开发人员认为将索引建全了就可以下班回家了，实则还有颇多的思量和陷阱。

3.1 索引列上不要进行计算
      这是最最普遍的失效陷阱，比如where trunc(order_date)=trunc(sysdate), i+2>4。索引失效的原因也简单，索引是针对原值建的二叉树，你将列值*3/4+2折腾一番后，原来的二叉树当然就用不上了。解决的方法:
　 1.　换成等价语法，比如trunc(order_date) 换成

where order_date>trunc(sysdate)-1 and order_date<trunc(sysdate)+1　 2.    特别为计算建立函数索引

create index Ｉ_XXXX on shop_order(trunc(order_date))    3.    将计算从等号左边移到右边
　这是针对某些无心之失的纠正，把a*2>4　改为a>4/2；把TO_CHAR(zip) = '94002' 改为zip = TO_NUMBER('94002');

3.2 CBO与索引选择性
     建了索引也不一定会被Oracle用的，就像个挑食的孩子。基于成本的优化器(CBO, Cost-Based Optimizer)，会先看看表的大小，还有索引的重复度，再决定用还是不用。表中有100 条记录而其中有80 个不重复的索引键值. 这个索引的选择性就是80/100 = 0.8，留意Toad里显示索引的Selective和Cardinailty。实在不听话时，就要用hints来调教。
     另外，where语句存在多条索引可用时，只会选择其中一条。所以索引也不是越多越好：）

3.3 索引重建
     传说中数据更新频繁导致有20%的碎片时，Oracle就会放弃这个索引。宁可信其有之下，应该时常alter index <INDEXNAME> rebuild一下。

3.4 其他要注意的地方
      不要使用Not，如goods_no != 2，要改为

where goods_no>2 or goods_no<2      不要使用is null , 如WHERE DEPT_CODE IS NOT NULL 要改为

WHERE DEPT_CODE >=0;3.5 select 的列如果全是索引列时
   又如果没有where 条件，或者where条件全部是索引列时，Oracle 将直接从索引里获取数据而不去读真实的数据表，这样子理论上会快很多，比如

select order_no,order_time from shop_order where shop_no=4当order_no,order_time,shop_no 这三列全为索引列时，你将看到一个和平时完全不同的执行计划。

3.6 位图索引
     传说中当数据值较少，比如某些表示分类、状态的列，应该建位图索引而不是普通的二叉树索引，否则效率低下。不过看执行计划，这些位图索引鲜有被Oracle临幸的。
 

4.减少查询往返和查询的表
这也是很简单的大道理，程序与Oracle交互的成本极高，所以一个查询能完成的不要分开两次查，如果一个循环执行１万条查询的，怎么都快不到哪里去了。

4.1 封装PL/SQL存储过程
　 最高级的做法是把循环的操作封装到PL/SQL写的存储过程里，因为存储过程都在服务端执行，所以没有数据往返的消耗。

4.2 封装PL/SQL内部函数
  有机会，将一些查询封装到函数里，而在普通SQL里使用这些函数，同样是很有效的优化。

4.3 Decode/Case
　 但存储过程也麻烦，所以有case/decode把几条条件基本相同的重复查询合并为一条的用法：

SELECT
 COUNT(CASE WHEN price < 13 THEN 1 ELSE null END) low,
 COUNT(CASE WHEN price BETWEEN 13 AND 15 THEN 1 ELSE null END) med,
 COUNT(CASE WHEN price > 15 THEN 1 ELSE null END) high
FROM products;4.4 一种Where/Update语法

SELECT TAB_NAME　FROM TABLES
WHERE (TAB_NAME,DB_VER) = （( SELECT TAB_NAME,DB_VER)
FROM TAB_COLUMNS WHERE VERSION = 604)

UPDATE EMP
SET (EMP_CAT, SAL_RANGE)
= (SELECT MAX(CATEGORY)FROM EMP_CATEGORIES)
5.其他优化
5.1RowID和ROWNUM
     连Hibernate 新版也支持ROWID了，证明它非常有用。比如号称删除重复数据的最快写法：

DELETE FROM EMP E
WHERE E.ROWID > (SELECT MIN(X.ROWID)
FROM EMP X
WHERE X.EMP_NO = E.EMP_NO);6.终极秘技 - Hints
   这是Oracle DBA的玩具，也是终极武器，比如Oracle在CBO,RBO中所做的选择总不合自己心水时，可以用它来强力调教一下Oracle，结果经常让人喜出望外。
   如果开发人员没那么多时间来专门学习它，可以依靠Toad SQL opmitzer 来自动生成这些提示，然后对比一下各种提示的实际效果。不过随着10g智能的进化，hints的惊喜少了。

7. 找出要优化的Top SQL
    磨了这么久的枪，如果找不到敌人是件郁闷的事情。
    幸亏10g这方面做得非常好。进入Web管理界面，就能看到当前或者任意一天的SQL列表，按性能排序。
    有了它，SQL Trace和TKPROF都可以不用了。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/calvinxiu/archive/2005/11/15/529756.aspx

豆瓣从今年开始也加入 Google Analytics 的统计阵营。让我们通过它加载的 Google Analytics 源码，简单分析一下它都是怎么应用的。

我们先从豆瓣的源码来看看它的Google Analytics统计代码

豆瓣 Google Analytics 代码

我们知道一般默认的 Google Analytics代码如下：

默认 Google Analytics 统计代码

两相对比，我们就会发现豆瓣加载 ga.js 的方式与默认的方式有些不太一样，由于豆瓣并没有采用 https 加密访问，所以撇弃了默认的ga.js加载方式。

默认的统计函数，pageTracker 也被豆瓣改成了 _ga ，这个只是名称定义上的区别，并没有什么实质的改变。豆瓣的主要应用是下面两个函数：

使用 _ga._addOrganic 识别非主流搜索引擎

再来看豆瓣比默认 Google Analytics 代码增加的部分，那就是多了数个 _ga._addOrganic ，这是 Google Analytics 添加自定义搜索引擎的代码。尽管 Google Analytics 对于主流的搜索引擎都能自动识别，但毕竟能识别的是国外的主流搜索引擎，在国内，像搜狐的 Sogou，QQ 的 soso，网易的有道等搜索引擎，都不能被 Google Analytics 正确识别，而被当作推荐来源。这时候我们就可以利用_addOrganic 参数来识别这些非主流搜索引擎，如豆瓣的做法。

使用 _addIgnoredOrganic 忽略关键字

除了添加自定义搜索引擎，豆瓣在最后还添加了如下这些代码:

_ga._addIgnoredOrganic("豆瓣");
_ga._addIgnoredOrganic("douban");
_ga._addIgnoredOrganic("豆瓣网");
_ga._addIgnoredOrganic("www.douban.com");

这些代码用来把引号中的关键词从搜索引擎的关键词报告中排除，而当成直接点击量来源。

为什么要这么做？因为一个知名的大网站，来自这些品牌词的搜索流量都非常大，常常是排在前几位的搜索关键词来源，而这通常是因为搜索引擎养成现在的人都懒得记网址，直接搜索品牌名来记住域名。这些品牌词对于网站的关键词来源分析并没有很直接的帮助，所以在来自品牌词的流量很大的情况下，可以直接把这些关键词识别成直接点击量来源。

关于自定义 Google Analytics 搜索引擎和排除特定关键词为直接点击量来源的语法，可以参考 Google Code 上关于这方面的详细介绍。

通过 _setVar 识别用户

当我们登录豆瓣后，再来分析豆瓣的源码，会发现多了一个ga._setVar(”xxxx”)的 Google Analytics 参数。

豆瓣使用 Google Analytics 的._setVar参数来跟踪登录用户行为

_setVar() 函数是 Google Analytics 的用户定义函数，主要用于对特定来源的用户行为进行分类，例如可以对登录浏览的用户设置一个数值，然后在 Google Analytics 后台的访问者/用户定义 中查看其浏览属性。

Google Analytics 访问者/用户定义报告

分析豆瓣的源码可以知道，豆瓣对每一个登录后的用户，都赋以一个专门的 id 值，这样可以在用户定义报告里，看到整体的登录用户访问行为，乃至每个登录用户的浏览行为。通过这样设定后，豆瓣便可以轻易获取高忠诚度访问用户的访问行为。关于_setVar()的更多说明，请参阅 Google Analytics的技术文档

如何根据访问者在我的网站上访问的页面或在表单上做出的响应对其进行分类？在 Google Analytics 官方的帮助文件，也给出了另外一个应用案例

值得注意的是，原来在设置 _setVar() 函数的时候，整个网站的跳出率会出现重大的偏差，不过在最近的google analytics官方博客，指出该bug已经修正，客户在进行这方面设置的时候，还是要注意对比前后数据是否有重大偏差。

通过 _trackPageview 区分不同类型的评论

豆瓣上的书评，影评和乐评可以说是豆瓣网站的核心价值所在。一般评论的URL格式如下：

豆瓣上单条评论的URL

当我们查看该页面的网页源代码时，会发现有趣的现象:

豆瓣单条评论页的 Google Analytics 代码

我们知道，一般 Google Analytics 的_trackPageview() 括弧中的参数是留空的， Google Analytics 会自动捕获网址的 URL 参数，如果在 _trackPageview()括弧中输入特定的数值，那么在 Google Analytics 的报表中，URL 将是我们指定的参数，而不再是我们在地址栏看到的 URL。

如上面的例子，我们在 Google Analytics 中看到的URL将是/book/review/1946018/，而不再是我们在浏览器地址栏看到的/review/1946018/

当所在频道是电影或者音乐时，_trackPageview() 中的参数将根据所在频道的属性，变为/movie/xxxxx 或者 /music/xxxxx的数值。

豆瓣通过对的参数进行重新指定，主要有以下的好处：

保证了用户和搜索引擎看到的 URL 比较简短，达到 URL 对用户友好和对搜索引擎友好的目的；而在 Google Analytics 报告中，通过 内容/内容细目/ 报告，又能了解到各个频道总的浏览情况。

在GA的内容细目报告中，将会多出 /book/ /music/ /movie/ 这样的文件夹来，总而获得各个频道的合计浏览数据。

而如果只是使用默认 _trackPageview()，你将只能得到所有评论页面的浏览数据，而无法得到细分的各个频道的浏览数据。

关于_trackPageview()的具体的使用方法可参照 Google Code 的说明

注意事项:使用 _trackPageview() 参数重新指定 URL 之后，网站覆盖图的数据将受到影响。可参阅 Google Analytics 的官方帮助文件

除了豆瓣使用 _trackPageview() 来对URL进行重写，大众点评网也采用了类似的做法（应该是比豆瓣更早采用。。。因为是我在点评网任职时候实验的做法;那时候豆瓣还没有使用 Google Analytis 统计代码，呵呵），有兴趣的同学可以自己去研究点评的 Google Analytis 代码。

文章来自：http://fairyfish.net/2009/06/30/google-analytics-in-douban/

----------------------------------------大众点评网的的代码，主页的
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-464026-1");
pageTracker._addOrganic("soso", "w");
pageTracker._addOrganic("sogou", "query");
pageTracker._addOrganic("yodao", "q");
pageTracker._addOrganic("bing", "q");
pageTracker._addOrganic("gougou", "search");
pageTracker._initData();
pageTracker._trackPageview("home/beijing_all");
</script>
     
   这个是子页面search/category/2/10/g328
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-464026-1");
pageTracker._addOrganic("soso", "w");
pageTracker._addOrganic("sogou", "query");
pageTracker._addOrganic("yodao", "q");
pageTracker._addOrganic("bing", "q");
pageTracker._addOrganic("gougou", "search");
pageTracker._initData();
pageTracker._trackPageview("dp_searchpv_card");
pageTracker._trackPageview("dp_searchpv_promo");
pageTracker._trackPageview("search/beijing_food_category/g328");
</script>
可以看出其中的pageTracker._trackPageview("。。。");是动态的也就是页面的，我们可以动态的赋值，这样就可以显示正确的地址了。

  大家如果有什么这方面的经验可以一同分享下。

   

CLOSE_WAIT状态的生成原因
通过TCP的状态图我们可以看出只有被动关闭的一端才有CLOSE_WAIT状态，当收到Fin并发送了Ack后
服务器状态就变成了CLOSE_WAIT状态，如果我们的服务器一直处于CLOSE_WAIT状态的话，说明套接字是被动关闭的！，并且没有发送Fin信令，原因往往是没有调用TCP的CloseSocket。

解决CLOSE_WAIT的方法:
1 一般原因都是TCP连接没有调用关闭方法。需要应用来处理网络链接关闭。
2 对于Web请求出现这个原因，经常是因为Response的BodyStream没有调用Close.
比如Widnows下:
使用HttpWebRequest 一定要保证GetRequestStream和GetResponse对象关闭，否则容易造成连接处于CLOSE_WAIT状态
3 TCP的KeepLive功能，可以让操作系统替我们自动清理掉CLOSE_WAIT的连接。
但是KeepLive在Windows操作系统下默认是7200秒，也就是2个小时才清理一次。往往满足不了要求。可以调小该数值。
Windows下的调整方法为
HKEY_LOCAL_MACHINE"CurrentControlSet"Services"Tcpip"Parameters下的以下三个参数：
KeepAliveInterval,设置其值为1000
KeepAliveTime,设置其值为300000(单位为毫秒，300000代表5分钟)
TcpMaxDataRetransmissions,设置其值为5

Close_Wait引发的问题:
Close_Wait会占用一个连接，网络可用连接小。数量过多，可能会引起网络性能下降，并占用系统非换页内存。 尤其是在有连接池的情况下(比如HttpRequest)
会耗尽连接池的网络连接数，导致无法建立网络连接

static

class StackVars
            {
            private int instVar;
            private static int staticVar;
            //存取堆栈变量
            void stackAccess(int val)
            {
            int j=0;
            for (int i=0; i<val; i++)
            j += 1;
            }
            //存取类的实例变量
            void instanceAccess(int val)
            {
            for (int i=0; i<val; i++)
            instVar += 1;
            }
            //存取类的 static 变量
            void staticAccess(int val)
            {
            for (int i=0; i<val; i++)
            staticVar += 1;
            }
            }
            

这段代码中的每个方法都执行相同的循环，并反复相同的次数。唯一的不同是每个循环使一个不同类型的变量递增。方法

stackAccess

使一个局部堆栈变量递增， instanceAccess 使类的一个实例变量递增，而 staticAccess 使类的一个 static 变量递增。

instanceAccess 和 staticAccess 的执行时间基本相同。但是， stackAccess 要快两到三倍。存取堆栈变量如此快是因为，JVM 存取堆栈变量比它存取 static 变量或类的实例变量执行的操作少。请看一下为这三个方法生成的字节码：

Method void stackAccess(int)
            0 iconst_0         //将 0 压入堆栈。
            1 istore_2         //弹出 0 并将它存储在局部分变量表中索引为 2 的位置 (j)。
            2 iconst_0         //压入 0。
            3 istore_3         //弹出 0 并将它存储在局部变量表中索引为 3 的位置 (i)。
            4 goto 13          //跳至位置 13。
            7 iinc 2 1         //将存储在索引 2 处的 j 加 1。
            10 iinc 3 1         //将存储在索引 3 处的 i 加 1。
            13 iload_3          //压入索引 3 处的值 (i)。
            14 iload_1          //压入索引 1 处的值 (val)。
            15 if_icmplt 7      //弹出 i 和 val。如果 i 小于 val，则跳至位置 7。
            18 return           //返回调用方法。
            Method void instanceAccess(int)
            0 iconst_0         //将 0 压入堆栈。
            1 istore_2         //弹出 0 并将它存储在局部变量表中索引为 2 的位置 (i)。
            2 goto 18          //跳至位置 18。
            5 aload_0          //压入索引 0 (this)。
            6 dup              //复制堆栈顶的值并将它压入。
            7 getfield #19 <Field int instVar>
            //弹出 this 对象引用并压入 instVar 的值。
            10 iconst_1         //压入 1。
            11 iadd             //弹出栈顶的两个值，并压入它们的和。
            12 putfield #19 <Field int instVar>
            //弹出栈顶的两个值并将和存储在 instVar 中。
            15 iinc 2 1         //将存储在索引 2 处的 i 加 1。
            18 iload_2          //压入索引 2 处的值 (i)。
            19 iload_1          //压入索引 1 处的值 (val)。
            20 if_icmplt 5      //弹出 i 和 val。如果 i 小于 val，则跳至位置 5。
            23 return           //返回调用方法。
            Method void staticAccess(int)
            0 iconst_0         //将 0 压入堆栈。
            1 istore_2         //弹出 0 并将它存储在局部变量表中索引为 2 的位置 (i)。
            2 goto 16          //跳至位置 16。
            5 getstatic #25 <Field int staticVar>
            //将常数存储池中 staticVar 的值压入堆栈。
            8 iconst_1         //压入 1。
            9 iadd             //弹出栈顶的两个值，并压入它们的和。
            10 putstatic #25 <Field int staticVar>
            //弹出和的值并将它存储在 staticVar 中。
            13 iinc 2 1         //将存储在索引 2 处的 i 加 1。
            16 iload_2          //压入索引 2 处的值 (i)。
            17 iload_1          //压入索引 1 处的值 (val)。
            18 if_icmplt 5      //弹出 i 和 val。如果 i 小于 val，则跳至位置 5。
            21 return           //返回调用方法。
            

查看字节码揭示了堆栈变量效率更高的原因。JVM 是一种基于堆栈的虚拟机，因此优化了对堆栈数据的存取和处理。所有局部变量都存储在一个局部变量表中，在 Java 操作数堆栈中进行处理，并可被高效地存取。存取 static 变量和实例变量成本更高，因为 JVM 必须使用代价更高的操作码，并从常数存储池中存取它们。（常数存储池保存一个类型所使用的所有类型、字段和方法的符号引用。）

通常，在第一次从常数存储池中访问 static 变量或实例变量以后，JVM 将动态更改字节码以使用效率更高的操作码。尽管有这种优化，堆栈变量的存取仍然更快。

考虑到这些事实，就可以重新构建前面的代码，以便通过存取堆栈变量而不是实例变量或 static 变量使操作更高效。请考虑修改后的代码：

class StackVars
            {
            //与前面相同...
            void instanceAccess(int val)
            {
            int j = instVar;
            for (int i=0; i<val; i++)
            j += 1;
            instVar = j;
            }
            void staticAccess(int val)
            {
            int j = staticVar;
            for (int i=0; i<val; i++)
            j += 1;
            staticVar = j;
            }
            }
            

方法 instanceAccess 和 staticAccess 被修改为将它们的实例变量或 static 变量复制到局部堆栈变量中。当变量的处理完成以后，其值又被复制回实例变量或 static 变量中。这种简单的更改明显提高了 instanceAccess 和 staticAccess 的性能。这三个方法的执行时间现在基本相同， instanceAccess 和 staticAccess 的执行速度只比 stackAccess 的执行速度慢大约 4%。

这并不表示您应该避免使用 static 变量或实例变量。您应该使用对您的设计有意义的存储机制。例如，如果您在一个循环中存取 static 变量或实例变量，则您可以临时将它们存储在一个局部堆栈变量中，这样就可以明显地提高代码的性能。这将提供最高效的字节码指令序列供 JVM 执行
转载自ibm