Java Websphere Application Server - 究竟需要什么才能快速启动？

Websphere Application Server - What on earth will it take to start any fast?

提问by Jay

I am using Rational Application Developer v7.0 that ships with an integrated test environment. When I get to debugging my webapp, the server startup time in debug mode is close to 5-6 minutes - enough time to take a coffee break!

我正在使用带有集成测试环境的 Rational Application Developer v7.0。当我开始调试我的 web 应用程序时，调试模式下的服务器启动时间接近 5-6 分钟 - 足够休息一下！

At times, it so pisses me off that I start cursing IBM for building an operating system instead of an app server! Spawning 20+ processes and useless services with no documented configuration to tuning it, to starting any faster.

有时，这让我很生气，以至于我开始诅咒 IBM 构建的是操作系统而不是应用程序服务器！产生 20 多个进程和无用的服务，没有记录的配置来调整它，以更快地启动。

I am sure there are many java developers out there who would agree with me on this. I tried to disable the default apps and a set of services via my admin console, however that hasn't helped much.

我相信有很多 Java 开发人员会同意我的看法。我试图通过我的管理控制台禁用默认应用程序和一组服务，但这并没有多大帮助。

I have no webservices, no enterprise beans, no queues, just a simple web app which requires a connection pool. Have you done something in the past to make your integrated test environment, start fast in debug mode and there by consume less RAM?

我没有 web 服务、没有企业 bean、没有队列，只有一个需要连接池的简单 web 应用程序。您过去是否做过一些事情来使您的集成测试环境在调试模式下快速启动并消耗更少的 RAM？

UPDATE: I tried disabling a few services (internationalization, default apps etc...) and now the WebSphere server went from bad to worse. Not only doesn't it take horrifying startup time, it keeps freezing every now and then for up to 2 minutes. :-( Sounds like, optimization is not such a good thing, always!

更新：我尝试禁用一些服务（国际化、默认应用程序等），现在 WebSphere 服务器变得越来越糟。它不仅不需要可怕的启动时间，而且时不时地冻结长达 2 分钟。:-( 听起来，优化并不是一件好事，总是！

采纳答案by Nick Holt

The best way to debug server code is to use remote debugging.

调试服务器代码的最佳方式是使用远程调试。

First you need to add the following to the JVM params in the server start script:

首先，您需要将以下内容添加到服务器启动脚本中的 JVM 参数中：

-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

This will cause the JVM to listen on the specified port, then from your IDE you can start a remote debug session against that port and debug as if the code was running in the same process.

这将导致 JVM 侦听指定的端口，然后您可以从您的 IDE 启动针对该端口的远程调试会话并调试，就像代码在同一进程中运行一样。

Working this way prevent you restarting the server so frequently and hence side-steps your problem with Websphere's start-up time.

以这种方式工作可以防止您如此频繁地重新启动服务器，从而避免了 Websphere 启动时间的问题。

You can get some odd results if the binaries on the server and the source in the IDE get out of sync but on the whole that's not a problem.

如果服务器上的二进制文件和 IDE 中的源文件不同步，您可能会得到一些奇怪的结果，但总的来说这不是问题。

回答by mh0rkk

If the connection pool really is the only appserver feature you use then why don't you simply use apache commons dbcp (http://commons.apache.org/dbcp/) drop webfear alltogether and use jetty instead. That should reduce your startup time to about 5 seconds. You can then later easily switch to websphere again for your production environment if you should really feel the need to.

如果连接池确实是您使用的唯一应用程序服务器功能，那么您为什么不简单地使用 apache commons dbcp ( http://commons.apache.org/dbcp/) drop webfear alltogear 并使用 jetty。这应该将您的启动时间减少到大约 5 秒。如果您真的觉得有必要，您可以稍后为您的生产环境轻松地再次切换到 websphere。

回答by Rich Seller

There's some hints and tips for tuning RAD 6 on developerworksthat may help, many of these also apply for RAD 7.

在 developerworks 上有一些调整RAD 6 的提示和技巧可能会有所帮助，其中许多也适用于 RAD 7。

I have seen a similar list for RAD 7, I'll post it if I can find it.

我已经看到 RAD 7 的类似列表，如果我能找到它，我会发布它。

I did find some tuning tips for Portal on RAD 7.

我确实在 RAD 7 上找到了一些针对 Portal 的调整技巧。

I would say my experience with the test environment has been suboptimal. I now tend to use Tomcat/Pluto configured for remote debugging with an External launch configurationto manage it from within bare Eclipse and rely on having appropriate JNDI configurations to abstract the underlying server.

我会说我在测试环境中的体验并不理想。我现在倾向于使用配置为远程调试的Tomcat/Pluto ，通过外部启动配置从裸 Eclipse 中管理它，并依靠适当的 JNDI 配置来抽象底层服务器。

If you are coding to the relevant APIs it shouldn't matter for development purposes that you're not on Websphere. If you do have a Webpshere specific issue you can always crank up the beast to debug it.

如果您正在对相关 API 进行编码，那么您不在 Websphere 上的开发目的应该无关紧要。如果您确实有 Webpshere 特定问题，您可以随时启动野兽来调试它。

回答by svachon

5 to 6 mins is not normal. I use RAD and WAS everyday and get decent startup times. Which version of WAS are you running and how much RAM do you have?

5 到 6 分钟是不正常的。我每天都使用 RAD 和 WAS 并获得不错的启动时间。您运行的是哪个版本的 WAS，您有多少 RAM？

If you share several workspaces and projects for a same WAS profile, consider creating a new WAS profile for your workspace.

如果您为同一个 WAS 配置文件共享多个工作空间和项目，请考虑为您的工作空间创建一个新的 WAS 配置文件。

You probably tried that but here's a simple check list of things to try on first hand. Make sure that your server settings in RAD has the following options enabled:

你可能尝试过，但这里有一个简单的检查清单，列出了可以直接尝试的事情。确保您在 RAD 中的服务器设置启用了以下选项：

• Optimize server for testing and developing
• Run server with resources on the workspace
• Minimize application files copied to the server

• 优化服务器以进行测试和开发
• 使用工作区上的资源运行服务器
• 最小化复制到服务器的应用程序文件

Uncheck "Enable universal test client" if you don't need it.

如果不需要，请取消选中“启用通用测试客户端”。

In the admin console you can verify some server settings such as

在管理控制台中，您可以验证一些服务器设置，例如

• Run in development mode
• Parallel start
• Start components as needed

• 在开发模式下运行
• 并行启动
• 根据需要启动组件

You can also uninstall the ivt app that comes installed by default when creating a new WAS profile. Then the usual things such as a drive that is not too fragmented and a pagefile size that is properly set.

您还可以卸载在创建新 WAS 配置文件时默认安装的 ivt 应用程序。然后是通常的事情，例如不太碎片化的驱动器和正确设置的页面文件大小。

And one last thing that you probably know already, republish to your server instead of restarting it.

您可能已经知道的最后一件事是重新发布到您的服务器而不是重新启动它。

回答by svachon

If you have no EJBs, no JMS, etc., just deploy under a standalone servlet container such as Tomcat or Jetty, you'll be amazed how fast it is :-), being ironic here but it's true!

如果您没有 EJB、没有 JMS 等，只需部署在一个独立的 servlet 容器（例如 Tomcat 或 Jetty）下，您会惊讶于它的速度有多快:-)，这里具有讽刺意味，但这是真的！

回答by duffymo

That's one reason why Spring was born.

这就是 Spring 诞生的原因之一。

You don't even have to give all the niceties like JMS, remoting, etc. You'd be better off with Tomcat, ActiveMQ, and OpenEJB.

您甚至不必提供 JMS、远程处理等所有细节。最好使用 Tomcat、ActiveMQ 和 OpenEJB。

Anythingbut WebSphere.

除了 WebSphere什么都没有。

回答by Manglu

WAS V7 addresses some of these problems by allowing you to configure what starts up when the app server starts up.

WAS V7 通过允许您配置应用服务器启动时启动的内容来解决其中的一些问题。

So if and when you migrate to WAS V7 you might seem some improvements in this space.

因此，当您迁移到 WAS V7 时，您可能会在这个领域看到一些改进。

回答by Robert H?glund

One of the main reasons is that you have a large application with many modules, classes, manifests, XML descriptors so on, and the fact that Websphere application server start up process is single threaded per se (thus each application may be started in a separate thread if they has equal weight). One other reason is that the Eclipse EMF and JST frameworks are very I/O intensive during startup and publish/deploy.

主要原因之一是您有一个包含许多模块、类、清单、XML 描述符等的大型应用程序，并且 Websphere 应用程序服务器启动过程本身是单线程的（因此每个应用程序可能在单独的线程中启动）线，如果它们具有相同的重量）。另一个原因是 Eclipse EMF 和 JST 框架在启动和发布/部署期间是非常 I/O 密集型的。

One other reason for the tedious start up is the annotation scanning which will occur during publish/deploy. This annotation scanning can be controlled and modified in a various ways. Look at this site: http://wasdynacache.blogspot.se/2012/05/how-to-speed-up-annotation-processing.html

启动繁琐的另一个原因是在发布/部署期间会发生注释扫描。可以以各种方式控制和修改该注释扫描。看这个网站：http: //wasdynacache.blogspot.se/2012/05/how-to-speed-up-annotation-processing.html

First of all, examine and evaluate your hardware, both CPU, memory and HDD. Is your processor/s running 100% for a long time during start up? If so, the processor may be too weak. Is paging occur? then you may have to put in some more RAM. The Websphere/eclipse JST and EMF frameworks are very I/O intense so you should consider to invest in a SSD disc. You should also make sure that other processes on your machine (virus protection software etc.) don′t steal hardware resources from the Websphere java processes.

首先，检查和评估您的硬件，包括 CPU、内存和硬盘。您的处理器在启动期间是否长时间 100% 运行？如果是这样，处理器可能太弱了。是否发生分页？那么你可能需要放入更多的内存。Websphere/eclipse JST 和 EMF 框架的 I/O 强度非常高，因此您应该考虑投资购买 SSD 磁盘。您还应该确保您机器上的其他进程（病毒防护软件等）不会从 Websphere java 进程中窃取硬件资源。

So for the hardware: 1. Processor - a pretty fast one, since the publish and the startup is mostly singlethreaded you do not need that many cpu cores 2. Memory - You will at least need 512Mb of physical RAM, this depends of the size of your application of course. 3. Storage - I would definitely go for a fast SSD since the underlying eclipse framework is I/O intensive.

所以对于硬件： 1. 处理器 - 一个非常快的处理器，因为发布和启动主要是单线程的，所以你不需要那么多 CPU 内核 2. 内存 - 你至少需要 512Mb 的物理 RAM，这取决于大小当然是你的应用程序。3. 存储 - 我肯定会选择快速 SSD，因为底层 eclipse 框架是 I/O 密集型的。

Here are some tricks to reduce the footprint of the start up phase. Please before applying these settings make sure that you record a baseline start up so that you can observe the difference in start up, i.e. the reduced start up time.

这里有一些技巧可以减少启动阶段的占用空间。请在应用这些设置之前确保您记录基线启动，以便您可以观察启动的差异，即减少的启动时间。

1. JVM args : -Xverify:none -Xquickstart -Xnoclassgc -XX:+UseNUMA -XtlhPrefetch -Xgcthreads4 (I got 4 virtual processors installed on my machine)
2. Extend the heap size to match the demands of your application.
3. Disable the autostart of the application to reduce publish time.
4. Disable PMI and unnecessary tracing.
5. Profile your application during startup and fix bottlenecks if found any.

1. JVM 参数：-Xverify:none -Xquickstart -Xnoclassgc -XX:+UseNUMA -XtlhPrefetch -Xgcthreads4（我的机器上安装了 4 个虚拟处理器）
2. 扩展堆大小以满足应用程序的需求。
3. 禁用应用程序的自动启动以减少发布时间。
4. 禁用 PMI 和不必要的跟踪。
5. 在启动期间分析您的应用程序并修复瓶颈（如果有）。

Other JVM arguments that may gain performance:

其他可能获得性能的 JVM 参数：

• com.ibm.cacheLocalHost=true
• com.ibm.ws.classloader.zipFileCacheSize=512
• com.ibm.ws.classloader.resourceRequestCacheSize=1024 ?
• com.ibm.ws.management.event.pull_notification_timeout =20000
• com.ibm.ws.amm.scan.context.filter.packages=true
• org.eclipse.jst.j2ee.commonarchivecore.disableZip=true

• com.ibm.cacheLocalHost=true
• com.ibm.ws.classloader.zipFileCacheSize=512
• com.ibm.ws.classloader.resourceRequestCacheSize=1024 ？
• com.ibm.ws.management.event.pull_notification_timeout =20000
• com.ibm.ws.amm.scan.context.filter.packages=true
• org.eclipse.jst.j2ee.commonarchivecore.disableZip=true

Jvm arguments that will make the Websphere application server to stop immediately:

将使 Websphere 应用程序服务器立即停止的 Jvm 参数：

• com.ibm.ejs.sm.server.quiesceTimeout=0
• com.ibm.ejs.sm.server.quiesceInactiveRequestTime=1000

• com.ibm.ejs.sm.server.quiesceTimeout=0
• com.ibm.ejs.sm.server.quiesceInactiveRequestTime=1000

Webcontainer properties:

网络容器属性：

• com.ibm.wsspi.jsp.disableTldSearch=true
• com.ibm.wsspi.jsp.disableResourceInjection=true

• com.ibm.wsspi.jsp.disableTldSearch=true
• com.ibm.wsspi.jsp.disableResourceInjection=true

JVM arguments that may be specified eclipse.ini (Note that the heap parameters is configured according to the conditions of my environment)

eclipse.ini中可能指定的JVM参数（注意heap参数是根据我的环境条件配置的）

• -Dcom.ibm.ws.management.event.max_polling_interval=5000
• -Xquickstart
• -Xverify:none
• -Xmxcl25000
• -Xjit:dataTotal=65536
• -Xcodecache64m
• -Xscmx48m
• -Xnolinenumbers
• -Xverify:none
• -Xmnx64m
• -Xmx1446m
• -Xmnx64m
• -XX:+UseCompressedOops
• -XX:+UseNUMA

• -Dcom.ibm.ws.management.event.max_polling_interval=5000
• -X 快速入门
• -Xverify：无
• -Xmxcl25000
• -Xjit:da​​taTotal=65536
• -Xcodecache64m
• -Xscmx48m
• -Xnolinenumbers
• -Xverify：无
• -Xmnx64m
• -Xmx1446m
• -Xmnx64m
• -XX:+UseCompressedOops
• -XX:+使用NUMA