Websphere Application Server - 到底需要什么才能快速启动？
我正在使用带有集成测试环境的 Rational Application Developer v7.0。 当我开始调试我的 web 应用程序时，调试模式下的服务器启动时间接近 5-6 分钟 - 足够的时间喝杯咖啡休息一下！
有时，这让我很生气，我开始咒骂 IBM 构建了一个操作系统而不是一个应用程序服务器！ 产生 20 多个进程和无用的服务，没有记录的配置来调整它，以更快地启动。
我确信有很多 Java 开发人员会同意我的观点。 我尝试通过管理控制台禁用默认应用程序和一组服务，但这并没有多大帮助。
我没有 Web 服务，没有企业 Bean，没有队列，只是一个需要连接池的简单 Web 应用程序。 您过去是否做过一些事情来使您的集成测试环境在调试模式下快速启动并消耗更少的 RAM？
更新： 我尝试禁用一些服务（国际化、默认应用程序等...），现在 WebSphere 服务器变得越来越糟糕。 它不但启动时间不长，而且时不时就会死机长达 2 分钟。 :-( 听起来，优化始终不是一件好事！
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!
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.
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.
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?
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
WAS V7 允许您配置应用程序服务器启动时启动的内容，从而解决了其中一些问题。
因此，如果您迁移到 WAS V7，您可能会发现这个领域有一些改进。
WAS V7 addresses some of these problems by allowing you to configure what starts up when the app server starts up.
So if and when you migrate to WAS V7 you might seem some improvements in this space.
如果连接池确实是您使用的唯一应用程序服务器功能，那么为什么不简单地使用 apache commons dbcp (http ://commons.apache.org/dbcp/）完全放弃 webfear 并使用 jetty 代替。 这应该会将您的启动时间减少到大约 5 秒。 如果您确实觉得有必要，稍后您可以轻松地在生产环境中再次切换到 websphere。
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.
如果您没有 EJB、没有 JMS 等，只需部署在独立的 servlet 容器（例如 Tomcat 或 Jetty）下，您会惊讶于它的速度有多快:-)，这里很讽刺，但这是真的！
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!
developerworks 上的 RAD 6 可能有一些调整提示和技巧帮助，其中许多也适用于 RAD 7。
我已经看到了 RAD 7 的类似列表，如果我能找到它，我会发布它。
我确实找到了一些针对 RAD 7 上 Portal 的调整技巧。
我想说我对测试环境的体验并不理想。 我现在倾向于使用配置为 远程调试的 Tomcat/Pluto外部启动配置从裸 Eclipse 中对其进行管理，并依靠适当的 JNDI 配置来抽象底层服务器。
如果您正在编写相关 API 的代码，那么出于开发目的，您不在 Websphere 上并不重要。 如果您确实遇到了 Webpshere 特定问题，您可以随时启动野兽来调试它。
There's some hints and tips for tuning RAD 6 on developerworks that may help, many of these also apply for RAD 7.
I have seen a similar list for RAD 7, I'll post it if I can find it.
I did find some tuning tips for Portal on RAD 7.
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 configuration to manage it from within bare Eclipse and rely on having appropriate JNDI configurations to abstract the underlying server.
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.
这就是 Spring 诞生的原因之一。
您甚至不必提供 JMS、远程处理等所有细节。使用 Tomcat、ActiveMQ 和 OpenEJB 会更好。
任何东西，除了WebSphere。
That's one reason why Spring was born.
You don't even have to give all the niceties like JMS, remoting, etc. You'd be better off with Tomcat, ActiveMQ, and OpenEJB.
Anything but WebSphere.
5到6分钟是不正常的。 我每天都使用 RAD 和 WAS，并且启动时间不错。 您运行的是哪个版本的 WAS？您有多少 RAM？
如果您为同一 WAS 配置文件共享多个工作区和项目，请考虑为您的工作区创建新的 WAS 配置文件。
您可能尝试过，但这里有一个简单的检查清单，列出了可以第一手尝试的内容。 确保 RAD 中的服务器设置启用了以下选项：
如果不需要，请取消选中“启用通用测试客户端”。
在管理控制台中，您可以验证一些服务器设置，例如
您还可以卸载创建新的 WAS 配置文件时默认安装的 ivt 应用程序。 然后是通常的事情，例如碎片不太多的驱动器和正确设置的页面文件大小。
您可能已经知道的最后一件事是，重新发布到您的服务器而不是重新启动它。
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?
If you share several workspaces and projects for a same WAS profile, consider creating a new WAS profile for your workspace.
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:
Uncheck "Enable universal test client" if you don't need it.
In the admin console you can verify some server settings such as
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.
And one last thing that you probably know already, republish to your server instead of restarting it.
主要原因之一是您有一个包含许多模块、类、清单、XML 描述符等的大型应用程序，并且 Websphere 应用程序服务器启动过程本身是单线程的（因此每个应用程序可以在单独的进程中启动）如果它们具有相同的重量，则为螺纹）。 另一个原因是 Eclipse EMF 和 JST 框架在启动和发布/部署期间 I/O 非常密集。
启动过程繁琐的另一个原因是在发布/部署期间进行注释扫描。 可以通过多种方式控制和修改该注释扫描。 看看这个网站：
http://wasdynacache.blogspot.se/2012 /05/how-to-speed-up-annotation-processing.html
首先，检查并评估您的硬件，包括 CPU、内存和 HDD。 您的处理器在启动过程中是否长时间 100% 运行？ 如果是这样，处理器可能太弱。 是否发生寻呼？ 那么你可能需要添加更多的内存。 Websphere/eclipse JST 和 EMF 框架的 I/O 非常密集，因此您应该考虑投资 SSD 磁盘。 您还应该确保计算机上的其他进程（病毒防护软件等）不会从 Websphere java 进程窃取硬件资源。
所以对于硬件来说：
1. 处理器 - 一个相当快的处理器，因为发布和启动大多是单线程的，所以不需要那么多的 cpu 核心
2. 内存 - 您至少需要 512Mb 的物理 RAM，这当然取决于您的应用程序的大小。
3. 存储 - 我肯定会选择快速 SSD，因为底层 eclipse 框架是 I/O 密集型的。
以下是一些减少启动阶段占用空间的技巧。 在应用这些设置之前，请确保记录基线启动，以便您可以观察启动的差异，即缩短的启动时间。
其他可能提高性能的 JVM 参数：
将使 Websphere 生效的 Jvm 参数应用程序服务器立即停止：
Web 容器属性：
eclipse.ini 可能指定的 JVM 参数（注意，堆参数是根据我的环境条件配置的）
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.
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
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.
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.
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.
Other JVM arguments that may gain performance:
Jvm arguments that will make the Websphere application server to stop immediately:
Webcontainer properties:
JVM arguments that may be specified eclipse.ini (Note that the heap parameters is configured according to the conditions of my environment)
调试服务器代码的最佳方法是使用远程调试。
首先，您需要将以下内容添加到服务器启动脚本中的 JVM 参数中：
这将使 JVM 侦听指定端口，然后从 IDE 您可以针对该端口启动远程调试会话并进行调试，就好像代码是在同一个进程中运行。
以这种方式工作可以防止您频繁地重新启动服务器，从而避免了 Websphere 启动时间的问题。
如果服务器上的二进制文件和 IDE 中的源代码不同步，您可能会得到一些奇怪的结果，但总的来说这不是问题。
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:
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.
Working this way prevent you restarting the server so frequently and hence side-steps your problem with Websphere's start-up time.
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.