websphere性能调整的一些体会和一些还不是很明白的问题(300分)

最近做了几个基于websphere的项目，最后感觉性能上都让人不太满意，
于是仔细研究了websphere的性能调整的文档，有些想法，也发现了一些问题，
希望提出来大家探讨一下。
1。http server websphere application server以插件形式集成到apach服务器中，
apach是基于进程机制的，但我发现随ibm websphere提供的ibm http server似乎已经
修改成线程机制了，无论客户端访问量如何增加，在内存中总是只有两个apach进程，
按照文档的说明，其中一个是主进程，另一个是子进程，而所有的http请求都由该子进程
响应。在http server的配置文件中可以设置子进程的最大线程数。我现在比较疑惑的是
ibm http server究竟是进程机制还是线程机制。
2关于servlet。 was以插件形式注册到http server中，于是http server会将servlet请求
转发给was，这里，was定义了一个队列，该队列存放了所有从http server转发过来的
servlet请求，我发现增加该队列的最大连接数设置可以从一定程度上改善性能，当然，
我的机器的资源是足以满足的。但有一个很奇怪的问题出现了，当客户端访问量比较大时，
客户端由于响应超时已经放弃了该连接，但是apach好像并不知道这一情况，它会持有该连接
并等待was返回对servlet的响应后一直试图向客户端写入响应结果，于是apach的活动连接数
上升很快，而且由于向客户端写入响应结果的操作事实上呈挂起状态，于是会导致was与
http server间的请求队列被阻塞，除非强制was重新生成请求队列，否则was会一直拒绝响应，
但事实上was并没有宕掉。
我想知道有没有办法可以让apach放弃掉客户端已经放弃的请求，并且，根据was文档介绍，
was在对于servlet转发请求队列的使用中存在一些bug，它不能很好的清理已经无效的请求，
那么有没有哪位在实际中碰到过类似的情况，有没有什么比较好的解决办法？
3。关于was请求队列的漏斗状结构。
按照was的文档，应该设置该队列的各个节点的最大连接数为一个漏斗状的前大后小的
形式，但基于前面的分析，这会导致was请求队列严重阻塞，不知各位对此有何看法。

我也发现过HTTP server会有一些问题。不过由于我的客户端访问量不大，所以还没有发生
小猪说的情况。
我用IBM Http server的时候，发生过好几次蓝屏错误，win2000的提示都是说崩溃发生在
IBM自己做的afpa模块中间。所以后来我就换成Apache 1.3.12了。
不过不管是apache还是Ibm http server,后来都出现过这样的情况：
我用http://server/webapplication/index.jsp这样的格式访问Index.jsp文件，但是有时候
就会发生从index.jsp中取得的username和password post到server端错误的情况。
肯定不是我程序的错误。

2。
HTTP AJPxx
HTTP Client <====> Apache <=====> WAS
A B C D
[这是结构，也是唯一我知道的东西了。以下内容均是我从这个结构猜测到的。]
我想超时设置应该有很多地方，上面我标了四处
A处：不管是网络报告超时还是client等的不耐烦了，client都没有理由gracefully
shutdown the connection（实际情况我不知道，但是），一旦client没有
gracefully shutdown the connection，那么apache将不会知道任何shutdown
的事情。 即使apache知道，如果apache没有关闭相应的AJP连接，那也会出现
你说的情况。
B处：如果apache内部处理超时，apache会以一个HTTP错误将这个错误汇报给client，
按你的情况看，这个超时比client的超时长，因此client不知道。 apache在这个
地方超时是有可能也有机会关闭相应的AJP连接的（实际情况我不知道）。
C处：与B处类似，如果apache处理，那么超时的时候关闭AJP连接时可能的。apache
也可以选择gracefully shutdown。但是很可惜，我觉得WAS在这个时候并不能
监测到这个shutdown。在Java中，ServerSocket.listen监听端口，与连接没关
系。而建实际连接的线程又正在忙着处理数据，没有机会去读写从Socket得到
的Stream，所以它并不知道连接已经断了，这能放着，等着。
D处：这是我唯一想到能处理你的问题的地方，那就是如果WAS监测到超时，就主动放弃
队列里的所有连接。或者定时ping一下那些连接看是不是有超时断掉的连接。可
是那不是你能干的，要问IBM去，呵呵
说了半天，答案就是“我不知道怎么处理，可能只能选个合适的超时和队列大小”

3。关于was请求队列的漏斗状结构。
呵呵，见笑。我没有想想出应该是什么形状。

没有用过这些东东。我发挥点想象力尽量附和一下吧
1。关于apache的“子进程最大线程数”，我了解到的是这样的。apache为了防止内存泄漏
规定子进程服役多少个请求后必须退役，退役后进程结束，产生新进程继续以后的请求。
而同一时间的多个请求依然是由同个进程服务的。如果同一时间并发请求太多，应该
会排队。

我这里倒是没有发生过崩溃的情况。我这里的websphere安装的
http server版本号是apache 1.3.12
我对apache的几个配置参数不是很明白，
我曾将keepalive设为off，开始时感觉很不错，因为所有的连接都会被
apache自己关闭掉，但是，由于apache已经将servlet
请求转发给was，所以当was返回响应结果时，apache会迅速打开数个连接，
如果客户端已经放弃该连接，则apache打开的连接会挂起，可用连接逐渐减少，
于是整个apach很快便停止响应了，当可用连接为0的时候。而且，挂起的连接很少
能够自己清除，昨晚我开了一晚上机，今天早上仍然拒绝访问。：（
现在整个问题的焦点就在于怎样能够设置apache的超时属性，我将配置文件中的
timeout设为30（默认为300），似乎意义不大。在keepalive为on的情况下，所有
打开的连接状态大部分为keepalive状态，少部分为write send message状态。而
默认的keepalivetimeout为15，已经很小了。
好像有很多访问量很大的网站都是使用apache的，不知道他们是怎么设置apache的。
当apache收到was返回的servlet响应时已经无法写回客户端，我想应该有办法让apache
放弃这个连接吧。

考虑中、、、

关注！

听...

对此不太了解！希望下面的文档对你有所帮助！
http://www-4.ibm.com/software/webservers/httpservers/library.html
另附：漏洞篇
对于Apache 1.3.3， 如果telnet 到 80 端口打以下指令会使用其拒绝服务:GET /DIR/%2e%2f%2e%2e%2e HTTP/1.0
在一个 http 请求之后加入特定数目的 '/'，就可以访问该 www 服务器的根目录以及所有子目录。
具体需要多少'/'，根据不同的版本和配置而不同。
对于 Apache 1.3.12 (Win32) on win98 ，如果在 http 请求后加 235 个'/'，就可以访问到根目录。
在Apache 1.3.12 on NT4 SP5 是 230 个 '/'。

我来学

昨天在saloris上试了一下，我设置apache的连接状态监视一直有问题，
用不起来，只好用saloris的netstat简单的查看了一下连接变动情况。
好像没有出现我上面提到的问题。在疯狂访问时连接数增长同样很快，
但一旦停止访问，连接数在很短的时间内就降下来了。apache本身的资源
回收机制应该是不会有变化的，看来问题还是出在nt上。昨天跟总部的一个
人讨论了一下，他讲我们公司有好几个项目用的webspher＋nt效果都不是很理想。
再联想到apache的官方网站上提供了apache在各种平台下的性能调整手册，
但单缺nt。不由得感叹一声，微软，破呀。

apache是基于进程的，在nt基于线程的机制下好像效率较低，apache2.0改进了
线程支持，在windows平台上的性能也有所提升
转贴：进程与线程效率的比较
每个任务一个进程（面向进程的）——运行程序的很多复本，每个复本每次只处理一个
任务。有时候，每次创建一个新任务都需要相应地创建一个新的进程（如inetd、Se
ndmail），但有些也设计成可以重用进程（如Apache）。这种体系结构在低负载的
情况下会产生很好的性能。在运行中等程度的负载时，如果进程影象比较小（如qmai
l）、已经实现了针对该应用程序的效率改进或者该类型的应用程序不会创建太多的同
时任务时，其性能也还可以。如果采用了进程缓冲技术并且同时运行的进程总数不是
很多（如中低程度的负载），就可以采用多CPU来解决问题。这种技术在所有的操作
系统上都可以实现，然而，从实现的的角度讲，UNIX明显地要比Windows更有效。（
Windows没有fork()系统调用，很少有Windows应用程序采用这种技术，因为它在W
indows上实在太慢了）。

每个任务一个线程（多线程）——只运行该程序的一个复本，在这个复本中，每个任务
都由一个单独的执行线程来处理。多线程应用程序在低-中负载情况下的性能非常好，
在更高的负载下，其性能就明显下降了（但通常也是可以接受的）。然而，超高负载
会将多线程应用程序带入死亡旋涡（death-spiral）。通常情况下，多线程应用程
序最多可以处理500到1000个并发的任务。这在大多情况下是可以接受的。每个新认
为使用一个新的线程，相对于新进程而言，新线程消耗更少的内存和更少的CPU处理
能力。仅仅最流行的UNIX变种（通常是商用操作系统）才能够在沉重的多线程负载下
保持稳定，所以很少有开放源码工程采用多线程技术。这种技术在多CPU上的性能可
能比在单CPU上的性能还要差，因为多处理器计算机上的信号量（semaphore）锁处
理的代价非常高。（多线程软件的例子有Netscape Web server和Apache on
Windows）

一个线程处理多个任务（异步处理）——程序的一个复本运行固定数量的线程（通常每
种类型的任务对应一个线程），每个线程通过一种称为异步（非阻塞）TCP/IP的技术
处理大量的同类型任务。因为大多数程序根本不需要处理高负载，并且异步编程非常
困难，所以很少有支持这种技术的程序出现。异步程序可以在多CPU计算机上平滑扩
展，因为它们大多采用彼此独立的长效线程。这种技术很少需要跨CPU的锁，因此每
个线程都可以永久且有效地分配给一个单独的CPU（如DNS BIND守侯进程daemon）

我看在nt上還是用weblogic的好，至少它是用自己的web server

多人接受答案了。