Jive在架构上主要是Jsp/Servlet，它的巨大并行处理能力主要是它的cache机制上，再加上充分利用Servlet的多线程机制，使它的速度表现极快。
同时，它的新的cache机制支持tangosol的Coherence(http://www.tangosol.com/index.jsp)，这是个集群环境下的
高速缓冲处理机制，因此，在访问量超过单台server容量时，可以通过简单的增加服务器提供并行处理能力。
我说的并行能力不佳是指并发当访问人数超过十五以上，我的系统性能急剧下降，（一般服务器，IBM CPU750 512M Win2K+Tomcat4.0+Apache2.0+JDK1.4+Sql_Server2K）如再有人访问，CPU使用率100%,机器几乎无法工作。此增加硬件效果不大。
另外，一个轻量级的Web版应用系统，如ＯＡ或ＣＲＭ等系统，业务不复杂，后台逻辑运算不复杂，主要依赖jdbc，要达到并发人数１００人以上，需要在哪几方面注意优化？
谢谢！
你的机器同时跑 Web Server 和数据库，这样不是很好
其实tomcat的servlet也是实现多线程机制，所以，你可能要修改你的程序，并发频繁的动作最好使用servlet.
修改tomcat的server.conf 增大其http线程数。
增加数据库连接池数目。
优化tomcat的bin/run.sh中Java命令行，如Java -server -Xms384 这样优化参数，如何具体使用参见我这里以前的帖子。
很多情况下（预算有限），用户不能有两台的服务器。
另外，有时，有些用户装备了两台好的服务器，Web Server,Sql_server分开，系统性能提升不理想，常是先数据库服务器CPU100%，接着Web Server CPU100%.
当然也有业务程序效率的部分原因，但我觉得业务程序也不至于差到只能并发十来个人。
我是用一个BaseServlet作为统一入口，作一些代理控制工作后，再分发到各个具体Servlet，这样，BaseServlet会不会成为一个瓶颈之一呢。
注：BaseServlet的工作不复杂，很简单的一些检测工作。
你说的 4000 人同时在线是什么意思？
在线有时只说明用户使用了 Session，但未必使用 CPU 资源.
这样不会，挺好，可能你再调整一下我上面说的外围参数，可以提高几倍以上的性能。
to iceant :
4000人同时在线，意思是同时操作，在10毫秒之内发出4000个request,接受到response后立即再发出4000个request,服务器端逻辑还是比较复杂的。
我没有使用容器，所以没有session，全部是线程和对象，这时linux下的CPU Idle是30
那一个Requst-Response的单位时间是多少?
你说的只是 10 毫秒内发出了 4000 个 request.
但是多少时间以后响应完呢? 这样的数据并不等同于 4000 用户在线!
这不是4000个用户在线，是4000个用户并发处理，实际用户在线可以更大。
我实属愚笨，确实不敢班门弄斧，可是实在无法附和。
就象一个笑话，一个县官说他骑一千里马回来，速度之快，以至于当他到衙门时，马的后半身还在京城。众属下不吭声，县官问一最善附会的属下为什么不说话，他说“老爷，马屁股都不在，实在没法拍！”
我不知道，板桥（郑老爷）做过应过应用程序吗？平均一个响应10毫秒，能同时响应4000人，也就是说40秒（不到一分钟）能响应完成！！
我得到一个还算比较准确的资料，SAP用四路CPU和一个G的内存来支持260个用户的响应，看来他们该考虑采用新的技术了。
我上周下载了Jive 的源程序，我不知这是不是最新的？我没有看到里边有Servlet.java.它所有逻辑全Jsp里，是jsp 1应用模式。后台业务主要有操作员，组，权限，消息，贴等，应该说，从这个角色，业务非常简单，应用系统中的任何一个模块都比这几个加起来都复杂得多，大概这是响应比较快的一个原因吧。如果说影响速度的地方，就树的模型及展示，但做过缓存，应该不成问题。
另外，我认为Jive有过分卖弄设计模式的嫌疑，设计模式是为应用服务，如果一个应用很稳定了，一个类很稳定，不再有扩展可能了，就没有使用抽象类的必要，否则就画蛇添足，而且在开发成本增加不少。除非这个论坛本身的目的就是向人展示它的设计技巧和面向对象技术的应用，而不是要怎样作论坛。Jive里的许多做法就是实验室里的做法（在论坛系统够用），到实际应用里，很多地方都要做改动。比如jsp 1模式在团队开发中简直就是无法推进；在类中写有大量SQL简直给测试带来巨大的工作量，使用prepareStatement，对于比较大的应用，无数的SQL和动态的SQL,那要耗多大的人力物力。
最后我想知道，有4000人同时访问J道论坛（非集群服务器，就一台Web服用器），4000都看到了响后的界面，大概共用多少时间？
我很敬仰Jive及板桥，我一直以非常虚心的态度来学习Jive，因为我正做一个应用系统，碰到并发压力的问题，本想能得到一点启发，也许能借鉴到我的系统，所以此贴绝抨击之意。
我其实对测试的标准有很多疑问，总是看到有人测试说一个系统能支持多少多少人同时在线。但是这个同时在线到底是什么意思？众说纷云。
而我觉得真正有用的数据就是:一个request-response 的时间是多少.
考虑 WEB 请求，一个页面里实际含有的请求其实很多。
比如，一个图片就会发一个请求，所以，要是真的测得能支持 4000 个Request,那能支持的人数只会更少，不会更多.
关于“SAP用四路CPU和一个G的内存来支持260个用户的响应”，我确实觉得他们应该采用新技术了，著名大公司往往就是在新技术以及创新上输给小公司。
另外终于知道，板桥大哥想立志做一开源项目，不好意思，上一帖对Jive使设计模式的说法因不明原委而过激了，开源项目与业务系统最大的区别就在于此，当然并不是说应用系统不在乎设计模式的使用，而是说存在一个平衡的做法，或者模式修正使用或模式退化使用。这话有点与一个技术人不相符，但对一个项目周期压力及特别要对此负责，谁都无法很萧洒。
从上周下载Jive以来，我又看几次，觉得它在处理Cache及权限代理很不错，特别是对所以对象都做了Cache，但对一个比较大的系统如ERP或CRM要完全处理好每个对象的Cache，难度要比这大得多。另外以我之见，觉得它整个MVC结构不是特合理，前端控制器也不是太清析，如果要这个开源项目非常顺利的推进下去，让更多的人进来开发，我觉得板桥大哥不必在Jive上开发，以板桥的能力，可以重新规划一个系统，借签Jive的优点，做了一个中国Java领域最牛的Open Source。
当然上次的话题“4000个用户并发处理”，除非有你说的"上面这个结果有很多附加条件，但是因为保密问题，所以无法在这里透露",否则我还是保留我的观点，尽管现在Java技术比96年（我是那时在校时才开始学的Java）进步很多，但有不少地方需要改进。当然这话题就此打住，网上是公平的，充许每一个人有自己的看法，不追求一致。