Tuning the application server is a complex activity which requires complete knowledge of the key server configuration files. JBoss application server has made a major change with release 5.0, moving from the JMX kernel to the newest POJO-based kernel. As a consequence, the configuration files and the memory requirements of the application server have changed as well.
• In the first part of this topic, we will introduce the basic system requirements of JBoss AS 4.x and 5.x releases and how to create a customized, faster server configuration, using just the services required by your applications.
• In the next part, we will examine how the application server provides its basic services by means of resource pooling, which is a technique used to control the server resources and improve the performance of the applications using these resources.
• At the end, we will learn how the logging service influences the performance of your applications and how to choose a configuration which reduces to a minimum the overhead of logs notifications.
From release 4.x to 5.x, and on
The JBoss project was initially developed in 1999 as a middleware research product. At that time, the application server provided barely an EJB container but, thanks to the interest of a growing community, the project quickly expanded to incorporate a complete portfolio of products.
One of the most important milestones of the project was release 4.x which is still the most used in production environments: this release, built on top of the highly successful 3.x line, was the first production-ready Java EE 1.4 application server in the industry.
Some of the key features of this innovative release are: full support for Java Web Services and Service Oriented Architectures (SOA), full integration with the Hibernate persistence framework, and improved clustering and caching support.
At the end of 2008, a new major release of the application server hit the industry. The long awaited 5.0 release was finally born: based on the new Microcontainer kernel which replaced the earlier JMX implementation in most application server areas, release 5.x provides also the latest implementation of Java EE 1.5 features along with the integration of many other standalone projects.
However, all these new features come at a price. As a matter of fact release 5.0 and its minor releases, demand a greater amount of resources (basically memory and CPU), so it is generally considered a heavyweight release compared to 4.x.
The truth is that the 5.x release was designed to be a completely modular and extensible one so it’s necessary to go beyond the basic configuration provided out of the box. Many developers experienced huge performance gains by selecting just a subset of services or by replacing the existing ones with custom services.
What about the future? release 5.x introduced a major change in the application server architecture, which is largely maintained also in the 6.x release. What we are expecting from the 6.x release is full integration with the newest Java EE 1.6 specifications, the complete integration of the POJO kernel and some important improvements in specific areas, like the Messaging system (HornetQ messaging system) and a new load balancing solution (mod_cluster).
Comparing server releases
At this point it could be useful to compare the requirements of different server versions. Release 4.x, based on the JMX kernel, has the advantage of being lighter compared to 5.x and 6.x. At startup, a default server configuration takes about 130 MB, committing half of this memory, and loading about 5,000 classes:
The new 5.x container effectively reproduces all the features of the 4.x JMX microkernel in the new POJO-based kernel. Compared with the older kernel, the new POJO kernel is based on the Microcontainer 2.0 project and offers a layered and easily extensible design (no references to JBoss classes) and much improved dependency injection and classloading.
What are the memory requirements of the new architecture? As you can see from the following image, at startup, the release 5.x of the application commits over double the amount of memory and loads about 10,000 classes:
One of the major complaints of developers is the amount of time needed to startup release 5.x of the application server which accounts to one about 90 seconds on a typical developer’s configuration:
12:01:58,138 INFO [Serverlmpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag= JBoss_5_1_0_GA date=200905221053)] Started in 1m:32s:375ms
Whereas release 4.x of the application server requires about 30 seconds for starting up:
11:52:09,766 INFO [Server] JBoss (MX MicroKernel) [4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)] Started in 34s:484ms
This sensible difference is due to the different amount of classes loaded by the two containers and also to the extensive custom meta data scanning executed by JBoss AS 5.x (see this resouce for more information: https://community.jboss.org/ wiki/JBoss5custommetadatafiles).
In order to speed up your development and reduce hardware demands, you should consider creating a customized JBoss AS 5.x server configuration, removing all services that are not required by your application. This strategy requires a minimum of knowledge of JBoss AS’s structure but it suits perfectly the nature of the application server, which allows deploying/undeploying services by means of simply adding and removing a file.
We will therefore dedicate the next section to learning how to provide a customized application server configuration.
Creating a custom application server configuration
Removing unwanted services from your configuration doesn’t have a direct impact on the performance of your application, but as a consequence of using less memory and threads, your application will benefit from the greater resources available and thus will indirectly meet the performance targets more easily.
The following histogram reveals (in percentage) the amount of memory engaged by a single service, along with the time spent for starting it up and the number of classes loaded:
What draws your attention immediately is the relevance of Seam libraries which include the new admin-console application, accounting for about 18% of the total memory and a detrimental 25% in the time spent for starting it up.
The admin-console has been included by default in release 5.1 of the application server and it provides a better administration interface than the jmx-console. However, from the performance point of view, you are strongly advised to remove this application from your server configuration.
JBoss AS 6.0.0 includes an experimental new feature called support for on-demand deployment of web applications. The main intent of this feature is to speed the startup of the AS in development and test environments by deferring the deployment of the management console applications that ship with the AS.
Convenient slimming targets also include Hypersonic Db, which is an in-memory pure Java database. Even if Hypersonic Db is adequate for developing and testing applications, you should replace it in production with a solid alternative. Consider removing the Mail Service as well and the Quartz Scheduler, if you don’t need to use a scheduler service.
Finally, the list of ‘minor services’ include a collection of services which are pretty useless for most applications like the JUDDI service, the Key Generator, BSH deployer, the XNIO-provider, SQL Exception Service, and JMX Remoting.
The Following is a table containing the checklist of services and how to remove them, borrowed from JBoss AS wiki:
|
Service |
Files / directories to be removed |
|
EJB3 services |
deploy/ejb3-connectors-jboss-beans.xml |
|
deploy/ejb3-container-jboss-beans.xml |
|
|
deploy/ejb3-interceptors-aop.xml |
|
|
deploy/ejb3-timerservice-jboss-beans.xml |
|
|
deploy/profileservice-secured.jar |
|
|
deployers/jboss-ejb3-endpoint-deployer.jar |
|
|
EJB 2 services |
deploy/ejb2-container-jboss-beans.xml |
|
deploy/ejb2-timer-service.xml |
|
|
JUDDI |
deploy/juddi-service.sar |
|
Key Generator |
deploy/uuid-key-generator.sar |
|
JMS |
deploy/messaging |
|
deploy/jms-ra.rar |
|
|
deployers/messaging-definitions-jboss-beans.xml |
|
|
Mail Service |
deploy/mail-service.xml |
|
deploy/mail-ra.rar |
|
|
Scheduling |
deploy/schedule-manager-service.xml |
|
deploy/scheduler-service.xml |
|
|
deploy/quartz-ra.rar |
|
|
Hypersonic DB |
deploy/hsqldb-ds.xml |
|
Jboss WS |
deploy/jbossws.sar |
|
deployers/jbossws.deployer |
|
|
Seam |
deploy/admin-console.war |
|
deployers/seam.deployer |
|
|
deployers/webbeans.deployer |
|
|
Minor services |
deployers/bsh.deployer deploy/hdscanner-jboss-beans.xml |
|
deployers/xnio.deployer |
|
|
deploy/jmx-remoting.sar |
|
|
deploy/profileservice-secured.jar deploy/ |
|
|
sqlexception-service.xml |
Please note that the juddi service ships just with the "standard" server configuration.
