本测试主要是模拟10，30，100个用户并发登陆的情况。
测试环境：
CPU ：core2 6300@1.86ghz
RAM ：2GB
OS ： winxp pro sp2（en）
Server ：tomcat5.1.7(java –Xmx768m，maxThread调为300)
DB ：MySQL5
JDK ：1.5.0_11
Tool ：LR
场景：
模拟10，30，100个超级用户并发登陆，成功登陆后都有权限并自动加载：calculate, clock, workflow, admin, communities, enterprise admin, calendar七个portlet
我在登陆动作submit前定义了集合点，登陆和每个portlet都定义了独立的事务，目的是看每个portlet加载的时间

10 vusers：5 seconds
 

30 vusers：15seconds

100 vusers：1 minute and 12 seconds

补充说明：这个数据在忽略网络带来的影响下进行的，往往很多在线系统对性能影响最大的还是网络。
简单分析：
由于在忽略网络影响的情况下进行测试，所以吞吐量和点击率的数据就显得不那么具参考价值，不过我们可以算算每次登陆每个用户的网络吞吐量大概是194,915b左右，大家可以结合自己当地的网络情况，计算一下需要多长时间去处理这个bytes。
一个比较乐观的结果是，从10个并发到100个并发都能全部pass
现在我们来看看login这个事务需要多长的时间，这里的login是输入密码后点登陆，从出现正在登陆的进度条，到页头出现的整个过程。我们先看看10个vusers的情况，90 per执行该事务需要1.847s，这个数字我认为很乐观，众所周知，liferay的登陆对用于进行了很复杂的认证，跑了几个process，设置了n次attribute，所以这个处理时间是很快的了。30个并发的时候，90％vusers通过的时间为4.362，这个时间有点长，但是从Std. Deviation这个值看来，不到0.4，所以我认为是相对的稳定，而响应时间都是可以接受的范围里。我们在看看100个并发时，时间高到26.762s，而Std. Deviation的值也比较大，这个时间是不能让人满意的，这点有一大部分的责任应该归咎于tomcat，因为tomcat处理高并发的性能确实不好。
现在我们来看看portlet的加载时间，因为portlet的加载是异步加载的，所以我们来抽取其中一个portlet来进行分析，我这里选择calendar。Calendar的加载时间从0.3 到1.248到8.686s，且标准差的值基本在0.5s范围内徘徊，所以说这个响应时间我认为是在一个可让人接受。

结论：
很多人说portal的性能不好，从上面的报表和分析可以看出，liferay portal的性能是不错的，这个结果和我一些项目的测试结果进行了一些比较，发觉portal的性能和一般的jsp，servlet作为展现层的性能是差不多的，借助于ajax，还有liferay多处缓存的设置，甚至有些性能还比传统的模式要优胜。所以，我认为一个公司启动一个项目的时候，考虑是否用liferay，不应该把评估的标准放在响应速度上，应该放在些别的方面，例如：liferay的学习成本比较高，不单单要先熟悉portal的标准，而且liferay的文档比较小，很多时候都是要直接debug源码去理解liferay。还有你的项目是否适合用portal，因为每个portlet都是代表一个比较独立的应用，如果portlet间的交互很多，用liferay会带来一定的难度，尽管都是可以实现。
另外：tomcat的并发性能确实不好，web的处理性能也不好，我加入了apr，据说可以用在生产环境，但是通过测试，结果也并不理想。
Liferay如果通过tomcat做集群，是件比较痛苦的事情，因为缓存和session同步要付出不少代价。
p.s.个人认为liferay是个优秀的项目，而且他的活动性很强，在很多企业需求功能上都有比较好的解决方案，可以省事不少。但是我认为liferay有点过度设计，代码比较冗余，可能这个很多是历史遗留下来的问题。
希望这篇文章能对大家有帮助：）