Java应用服务器性能 [英] Java Application Server Performance
问题描述
我在Sun Application Server 8.1上运行了一个有点过时的Java EE应用程序（又名SJSAS，Glassfish的前身）。如果有500多位同时在线的用户，应用程序的速度会变得难以接受，我正在帮助确定大部分执行时间花费在哪里，以及如何加快执行速度。到目前为止，我们一直在使用LoadRunner，应用服务器日志，Oracle statpack，snoop，调整应用服务器接受者和会话（工作者）线程，调整Hibernate批量大小以及加入获取使用等来进行实验和测量，但是在初始获益后我们正在努力改进问题。
好的，通过这个问题的介绍，下面是一个真正的问题：如果在一个盒子上运行缓慢的Java EE应用程序其CPU和内存使用率从未达到20％以上，并且有500多个用户运行时，显示了两件事情：1）即使在同一个应用程序服务器JVM进程中请求甚至静态文件也非常慢，以及2）请求超出应用程序服务器JVM进程，但在同一个盒子上速度很快，您会调查什么？
我的想法最初跳转到应用程序服务器线程，包括acceptor和session线程，即使对静态文件的请求正在排队，等待一个可用的线程，我如果CPU /内存没有真正纳税，那么更多的线程才能完成。但之后我们大幅增加了接受者和会话线程，并且没有任何改进。
澄清编辑：
$ b 1）静态文件应该由Web服务器提供，而不是应用服务器。我使用的事实是，在我们的例子中（不幸的是）不是这样的配置，所以我可以看到它不执行的文件的应用服务器性能 - 因此排除了任何数据库性能成本等。
$ b $ 3）JVM堆大小（Xmx）设置为1GB。
感谢您的帮助！
使用Sun性能监控工具后，我们发现垃圾收集器正在运行每隔几秒钟，1GB堆中只有大约100MB被使用。所以我们尝试添加下面的JVM选项，到目前为止，这个新配置作为极大地改善了性能。
-XX：+ DisableExplicitGC -XX ：+ AggressiveHeap
请参阅 http://java.sun.com/docs/performance/appserver/AppServerPerfFaq.html
我们的经验：不要留下JVM选项调整和垃圾收集调整到最后。如果您遇到性能问题，请在排查过程中尽早查看这些设置。
I've got a somewhat dated Java EE application running on Sun Application Server 8.1 (aka SJSAS, precursor to Glassfish). With 500+ simultaneous users the application becomes unacceptably slow and I'm trying to assist in identifying where most of the execution time is spent and what can be done to speed it up. So far, we've been experimenting and measuring with LoadRunner, the app server logs, Oracle statpack, snoop, adjusting the app server acceptor and session (worker) threads, adjusting Hibernate batch size and join fetch use, etc but after some initial gains we're struggling to improve matters more.
Ok, with that introduction to the problem, here's the real question: If you had a slow Java EE application running on a box whose CPU and memory use never went above 20% and while running with 500+ users you showed two things: 1) that requesting even static files within the same app server JVM process was exceedingly slow, and 2) that requesting a static file outside of the app server JVM process but on the same box was fast, what would you investigate?
My thoughts initially jumped to the application server threads, both acceptor and session threads, thinking that even requests for static files were being queued, waiting for an available thread, and if the CPU/memory weren't really taxed then more threads were in order. But then we upped both the acceptor and session threads substantially and there was no improvement.
Clarification Edits:
1) Static files should be served by a web server rather than an app server. I am using the fact that in our case this (unfortunately) is not the configuration so that I can see the app server performance for files that it doesn't execute -- therefore excluding any database performance costs, etc.
2) I don't think there is a proxy between the requesters and the app server but even if there was it doesn't seem to be overloaded because static files requested from the same application server machine but outside of the application's JVM instance return immediately.
3) The JVM heap size (Xmx) is set to 1GB.
Thanks for any help!
After using a Sun performance monitoring tool we found that the garbage collector was running every couple seconds and that only about 100MB out of the 1GB heap was being used. So we tried adding the following JVM options and, so far, this new configuration as greatly improved performance.
-XX:+DisableExplicitGC -XX:+AggressiveHeap
See http://java.sun.com/docs/performance/appserver/AppServerPerfFaq.html
Our lesson: don't leave JVM option tuning and garbage collection adjustments to the end. If you're having performance trouble, look at these settings early in your troubleshooting process.
这篇关于Java应用服务器性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
