Linux 上的 liferay 性能问题
我在两台机器上安装了 Liferay 6 和 Tomcat 系统:
机器1: Windows 2003 服务器 2GB 内存,2Gh CPU Mysql 版本 14.14 分发 5.1.49 Liferay 6.0.6 与 Tomcat 6
<代码> 机器2: Linux CentOS 5.5 4GB 内存,2Gh CPU Mysql 版本 14.14 分发 5.5.10 Liferay 6.0.6 与 Tomcat 6 两个
liferay系统都有相同的启动参数和mysql配置。 liferay 系统包含一个自定义主题和一个检查每个 URL 访问的 servlet 过滤器挂钩。
我们编写了一个 Grinder 脚本来测试从 50 个并发用户
开始的系统负载。
测试脚本执行以下操作:
- 打开主页
- 使用用户名/密码登录
- 输入安全密钥(自定义 portlet)
- 移至私人社区
- 注销
在 Windows 系统上,响应时间符合预期(Grinder 中每次测试的平均时间接近 40 秒) 。 然而在Linux系统上,相同操作的响应时间太长(接近4分钟)。
我们尝试修改 mysql、tomcat、连接池和其他一些参数,但结果都是一样的。另外,liferay 也使用另一台机器的 mysql 进行了测试(机器 1 liferay -> 机器 2 mysql),
我们在测试环境中以及客户端的 Linux 机器上都面临着同样的问题。
I have Liferay 6 with Tomcat system setup on two machines:
Machine 1:
Windows 2003 Server
2GB RAM, 2Gh CPU
Mysql Ver 14.14 Distrib 5.1.49
Liferay 6.0.6 with Tomcat 6
Machine 2:
Linux CentOS 5.5
4GB RAM, 2Gh CPU
Mysql Ver 14.14 Distrib 5.5.10
Liferay 6.0.6 with Tomcat 6
Both the liferay systems are having identical startup parameters and mysql configurations.
The liferay system contains a custom theme and a servlet filter hook checking each URL access.
We have written a Grinder script to test the load of the system starting with 50 concurrent users
.
The test script does the following things:
- Open home page
- Login with username/password
- Enter security key (custom portlet)
- Move to a private community
- Logout
On Windows system the response time is as expected (nearly 40 seconds mean time for each test in Grinder).
However on the Linux system the response time is too high (nearly 4mins) for the same operations.
We tried revising the mysql, tomcat, connection pool and few other parameters but all resulting the same. Also the liferay were tested using mysql of the other machine (machine 1 liferay -> machine 2 mysql)
We are facing the same issue on Linux machines in our test environment and also at our client's end.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这看起来像是一个重复的问题。我怀疑您的问题与内存/jvm 配置以及特别是垃圾收集有关。小负载下的高 CPU 利用率往往指向这个方向。
This looks like a duplicate question. I suspect your issue is related to memory / jvm configuration and specifically garbage collection. High CPU utilization under small loads tend to point in that direction.
在您的 Grinder 脚本中,您是否将每个步骤设置为单独的事务?这将使您能够看到每个步骤花费了多少时间。了解是否一切都全面变慢,或者是否只有一种交易类型减慢了您的速度,这可能会很有用。
另外,Linux 机器上的 Tomcat 日志中是否有您在 Windows 上看不到的内容?意外的 java 堆栈跟踪等?
最后,每台机器上的数据库是否相同?他们拥有相同数量的数据吗?他们有相同的索引吗?
编辑:是一笔交易占用了所有额外的时间,还是每笔交易都比较慢?当您在 Linux 机器上运行“top”时,是 Tomcat Java 进程占用了您的所有 CPU,还是其他进程?
In your Grinder script, have you set each of the steps as a separate transaction? This will allow you to see how much time each step is taking. It might be useful to know if everything is slower across the board, or if it's just one transaction type that's slowing you down.
Also, is there anything in the Tomcat logs on the Linux box you aren't seeing on windows? Unexpected java stack traces, etc?
Finally, are the databases on each machine identical? Do they have the same amount of data? Do they have the same indexes?
edit: Is it one transaction that's taking up all the extra time, or is each transaction slower? When you run 'top' on your linux box, is it the tomcat java process that's eating all your CPU, or some other process?