Preface
This advice is primarily on how to tune and/or slim JBossAS. The two concepts are orthogonal in most cases. While reducing idle service threads through slimming won't have a large impact on performance, using less memory and resources may allow you to tune other performance aspects. Of course this does reduce startup time. Furthermore, as a general security concept -- remove services you don't use. We will separate the two categories: slimming and tuning. We start by using the default configuration and trimming from there (for clustering that will be the topic of a later wiki page ;-) ). This advice does not involve areas of tuning that crosscut developer and administrative roles (application tuning such as cache sizes). This is primarily advice for administrative tuning.
Note for those concerned that this advice will make a technically non-J2EE-compliant instance of JBoss (3.2.6 is not compliant anyhow) as removing key J2EE services would cause JBoss to fail the TCK. Most performance tuning/administrative tasks done in real-world installations technically fall in this category.
Assume that you have copied the server/default directory and its subdirectories to server/slim.
Tuning
Java Virtual Machine
- TuneVMGarbageCollection or Tune JDK 5 Garbage Collection
for your machine and memory size
- Use a 64 bit machine and 64 bit VM so that you can use large heap sizes, larger than 2-4GB typically. 64 bit support is available on all recent SPARC/Solaris boxes running Solaris 9 or later, Itanium with JDK 1.4, or JDK 5 on Linux x64.
- DO NOT USE -d64 (64-bit) if you do not use ABOVE the maximum 32 bit heap space (2-4 GB of heap). Using 64 bit addressing requires MORE memory to do the same amount of work and provides no advantage for applications that do not need this much memory.
- Avoid extra large heaps but avoid extra small heaps. (We cannot tell you what qualifies because it depends on what you're doing). This affects generational garbage collection and total time to scan the heap. It is difficult to tune a small heap effectively (even if your app only uses 200MB, if you're using parallel garbage collection + CMS, then you're going to need well above 512MB). Oversize heaps spend needless time scanning memory for garbage collection.
- Avoid the Sun 1.4 VM. JDK 5 is VASTLY better especially in the area of garbage collection.
- Use the -server option but use either of -XX:ThreadStackSize?=128k (Solaris) or -Xss128k (every other platform). On Solaris -Xss128k does nothing (you can only set LARGER thread stack sizes). This allows you to create more threads by using less memory per thread but might result in blown stacks with extremely recursive code. Still, 128k stack is still nothing to shake a stick at.
- You really need to understand generational garbage collectors to tune this properly and you really have to do load testing (OpenSTA?, JMeter, etc) to know for sure.
- You really should use a multi-processor machine with more than 2 processors and use various parallel and concurrent garbage collection options (we cover this in Advanced JBoss Training hint hint) for maximum performance and high garbage collector throughput. However, you really need to understand how garbage collection works to tune this well. JDK 5 is mostly self-tuning.
- JDK 1.4's default NewSize is not a good guess. Bad rule of thumb: < 20% is a good NewSize. Above 20% is dangerous due to a nasty JDK bug which can cause it to psychotically run all full garbage collections and never unsuspend or free up enough memory. JDK 5 does not seem to exhibit this bug and seems to pick more sane defaults.
JBoss/Java on Linux
If you are running JBoss AS on a Linux server, you should read this article written by Andrew Oliver, one of JBoss, a division of Red Hat, consultants on how tune JBoss/Java in a Linux server
Tomcat
- Edit your server/slim/jbossweb-tomcat5?.sar/server.xml
- Check the XML document for connectors you are using. For example, the HTTP connector:
<Connector port="8080" address="${jboss.bind.address}"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"/>
- You should have enough threads (maxThreads) to handle (rule of thumb) 25% more than your maximum expected load (concurrent hits coming in at once)
- You should have minSpareThreads equal just a little more than your normal load
- You should have maxSpareThreads equal just a little more than your peak load
-
minSpareThreads
means "on start up, always keep at least this many threads waiting idle" -
maxSpareThreads
means "if we ever go above minSpareThreads then always keep maxSpareThreads waiting idle"
- Remove any unnecessary valves and logging. If you're not using JBoss's security, remove the security valve (see below).
- Precompile JSPs. (The built-in compiler is fairly fast, it may not be worthwhile for small sites.)
- Turn off "development" mode in you sever/slim/jbossweb-tomcat50.sar/conf/web.xml
RMI for Remote Invocations
By default, JBoss creates a new thread for every RMI request that comes in. This is not generally efficient on a large system. Secondly, it can be dangerous to allow unrestrained connections in the case of performance or traffic spikes or run-away connection creating clients. To remedy this you should consider switching to the pooled invoker.
- Edit server/slim/conf/standardjboss.xml
- Change all of the proxy bindings to the pooled invoker by changing every XML fragment reading:
<invoker-mbean>jboss:service=invoker,type=jrmp</invoker-mbean>
to
<invoker-mbean>jboss:service=invoker,type=pooled</invoker-mbean>
JBoss also has a mostly undocumented PooledInvokerHA you may try.
Log4j
Logging has a profound effect on performance. Changing the logging level to TRACE can bring the JBossAS to a crawl. Changing it to ERROR (or WARN) can speed things up dramatically.
- By default, JBoss logs both to the console and server.log and by default it uses level "INFO".
- Consider not logging to System.out (you may still want to redirect it to catch JVM errors)
- Consider changing the log level to ERROR. Remember that JBoss watches its log4j config file for changes and you can always change configuration at runtime.
- Add a category filter for your Java class hierarchy.
To turn off console logging:
- Edit server/slim/conf/log4j.xml
- Change the following XML fragment:
<root> <appender-ref ref=CONSOLE"/> <appender-ref ref="FILE"/> </root>
make it read
<root> <appender-ref ref="FILE"/> </root>
- You can then remove this fragment:
<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="Target" value="System.out"/>
<param name="Threshold" value="INFO"/>
<layout class="org.apache.log4j.PatternLayout">
<!-- The default pattern: Date Priority [Category] Message\n -->
<param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
</layout>
</appender>
To change the log level:
- Edit server/slim/conf/log4j.xml
- Remove/comment these XML fragments:
<category name="org.apache"> <priority value="INFO"/> </category> <!-- Limit org.jgroups category to INFO --> <category name="org.jgroups"> <priority value="INFO"/> </category>
- Change the root category by changing this XML fragment:
<root> <appender-ref ref="CONSOLE"/> <!-- you may have removed this earlier --> <appender-ref ref="FILE"/> </root>
to look like this
<root> <priority value="ERROR" /> <appender-ref ref="CONSOLE"/> <!-- you may have removed this earlier --> <appender-ref ref="FILE"/> </root>
And finally, probably the most important thing in log4j, make sure you limit the logging level on your own class hierarchy. This assumes that you are using log4j as it was intended and not writing everything to System.out. This will significantly reduce the overhead of log4j and allow you to fully enjoy the benefits of calls like
if (log.isDebugEnabled())...
. If you don't do this then all the logging in your code will get formatted and passed to the appender, and the threshold on the appender will weed out the log messages. This can generate a significant amount of garbage. Assuming your java package starts with "a.b", add something like this to log4j.xml:
<!-- Limit a.b category to INFO --> <category name="a.b"> <priority value="INFO"/> </category>
This can be added in the same area where you find the category filters for org.apache and org.jboss (see above).
Deployment Scanner
- The deployment scanner scanning every 5 seconds eats up cycles especially on systems with a slow filesystem (*cough* NTFS *cough*).
- See the below slimming stuff on how to turn the number of seconds such that it happens less frequently or not at all
Stateless Session Beans
- EJB 1.x-2.x stateless session beans operate with an ill-advised pooling model (required by the specification). If you find that you need more than the default (10) instances consider setting the minimum pool size:
edit
server/slim/conf/standardjboss.xml
, scroll down to:
<container-configuration> <container-name>Standard Stateless SessionBean</container-name> <call-logging>false</call-logging> <invoker-proxy-binding-name>stateless-rmi-invoker</invoker-proxy-binding-name> <container-interceptors>
and find:
<container-pool-conf> <MaximumSize>100</MaximumSize> </container-pool-conf> </container-configuration>
change it to read:
<container-pool-conf> <MinimumSize>100</MinimumSize> <MaximumSize>100</MaximumSize> <strictMaximumSize/> <strictTimeout>30000</strictTimeout> </container-pool-conf> </container-configuration>
For the most part a server environment doesn't want these pools growing and shrinking (because it causes memory-fragmentation and thats worse than latent heap usage). From a performance standpoint, the nuber should be big enough to serve all your requests with no blocking.
CMP tuning
- Read this: http://www.artima.com/forums/flat.jsp?forum=141&thread=24532
- and this: http://www.onjava.com/pub/a/onjava/2003/05/28/jboss_optimization.html
- now ditch CMP and use JBossHibernate instead
Connection Pools
- Don't use XA versions unless you really know you need them. XA connections do not have good performance.
- Use database specific "ping" support where available for "check-connection" or use database-specific driver fail-over support rather than checking connections at all. (remember that not all tuning options may be feasible in your environment, we're talking optimal)
Slimming
When not using the mail-service (J2EE standard JavaMail client)
- remove server/slim/deploy/mail-service.xml
- remove server/slim/lib/mail* (mail-plugin.jar, mail.jar - JavaMail stuff)
- remove server/slim/lib/activation.jar (Java Activation Framework is used by JavaMail)
When not using the cache invalidation service (used for CMP Option A beans with Cache Invalidation usually in a clustered configuration)
- remove server/slim/deloy/cache-invalidation-service.xml
When not using the J2EE client deployer service (this is a not very useful J2EE spec required service for the EAR application-client.xml descriptor)
- remove server/slim/deploy/client-deployer-service.xml
When not using the integrated HAR deployer and Hibernate session management services
- remove server/slim/deploy/hibernate-deployer-service.xml (HAR support)
- remove server/slim/lib/jboss-hibernate.jar (HAR support)
- remove server/slim/lib/hibernate2.jar (Hibernate itself)
- remove server/slim/lib/cglib-full-2.0.1.jar (used by Hibernate to create proxies of POJOs)
- remove server/slim/lib/odmg-3.0.jar (some goofy object-relational mapping thing used by hibernate from some goofy committee http://www.service-architecture.com/database/articles/odmg_3_0.html)
When not using Hypersonic (which you should not in production)
Note that JBossMQ as deployed in the default configuration uses DefaultDS with mappings for Hypersonic. See JBoss MQ Persistence Wiki pages for more information on configuring other alternatives.
- remove server/slim/deploy/hsqldb-ds.xml
- remove server/slim/lib/hsqldb-plugin.jar
- remove server/slim/lib/hsqldb.jar
When not using JBossMQ (our JMS server)
- remove the entire server/slim/deploy/jms directory
- remove server/slim/lib/jbossmq.jar
When not using the HTTPInvoker (which lets you tunnel RMI over HTTP)
- remove the entire server/slim/deploy/http-invoker.sar directory
When not using XA datasources (Distributed and/or recoverable transactions)
- remove server/slim/deploy/jboss-xa-jdbc.rar
If you do not need the JMX-Console then remove it
- remove server/slim/deploy/jmx-console.war
- Otherwise Secure it
If you do not need to make JMX calls over RMI (warning the shutdown.sh DOES do this)
- remove server/slim/deploy/jmx-invoker-adaptor-server.sar
- remove server/slim/deploy/jmx-adaptor-plugin.jar
- or you may want to just secure the JMX invoker-adaptor instead
If you do not need the web-console
- remove server/slim/deploy/management/web-console.war
If you do not need JSR-77 extensions for JMX
- remove server/slim/deploy/management/console-mgr.sar
If you need neither the web-console or jsr-77 extensions
- remove server/slim/deploy/management directory entirely
If you are not using console/email monitor alerts
- remove server/slim/deploy/monitoring-service.xml
- remove server/slim/lib/jboss-monitoring.jar
If you are not using rich property editors (JMX) or loading properties into system properties via the Properties Service
- remove server/slim/deploy/properties-service.xml
- remove server/slim/lib/properties-plugin.jar
The scheduler-service.xml is an example unless you have put your own in it
- remove server/slim/deploy/scheduler-service.xml
If you are not using the JBoss Scheduler Manager (allows you to schedule invocations against MBeans)
- remove server/slim/deploy/schedule-manager-service.xml
- remove server/slim/lib/scheduler-plugin* (scheduler-plugin.jar, scheduler-plugin-example.jar)
If you do not need vendor-specific sql exception handing (just leave it, really)
- remove server/slim/deploy/sqlexception-service.xml
If you are using neither client-side transaction management nor cached connections (where instead of pooling we cache connections such as in the case of JAAS->DB User -- using this means you are a bad person and need to be smacked)
- remove server/slim/deploy/user-service.xml
If you do not use JBoss UUID key generation (often used with CMP primary keys, but we have database specific support as well)
- remove server/slim/deploy/uuid-key-generator.sar
- remove server/slim/lib/autonumber-plugin.jar
user-service.xml is an example -- unless you put something in it (your own mbeans) you can always remove it.
- remove server/slim/deploy/user-service.xml
If your users directly connect to Tomcat via HTTP and do not pass through Apache/mod_jk:
- open server/slim/deploy/jbossweb-tomcat50.sar/server.xml in the vi editor
- remove/comment the following XML fragment:
<!-- A AJP 1.3 Connector on port 8009 -->
<Connector port="8009" address="${jboss.bind.address}"
enableLookups="false" redirectPort="8443" debug="0"
protocol="AJP/1.3"/>
If your users do not directly connect to Tomcat via HTTP and always pass through Apache/mod_jk
- open server/slim/deploy/jbossweb-tomcat50.sar/server.xml in the vi editor
- remove/comment the following XML fragment:
<!-- A HTTP/1.1 Connector on port 8080 -->
<Connector port="8080" address="${jboss.bind.address}"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"/>
If you do not need to be able to deploy EAR files
- open server/slim/conf/jboss-service.xml in the vi editor
- remove/comment the following XML fragments from the
from under the
<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"
MBean
<attribute name="EARDeployer">jboss.j2ee:service=EARDeployer</attribute>
and
<!-- EAR deployer, remove if you are not using Web layers --> <mbean code="org.jboss.deployment.EARDeployer" name="jboss.j2ee:service=EARDeployer"> </mbean>
If you do not need to be able to deploy JMS Queues
- open server/slim/conf/jboss-service.xml in the vi editor
- remove/comment the following XML fragments from the
from under the
<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"
MBean
<attribute name="JMSService">jboss.mq:service=DestinationManager</attribute>
If you do not need to use CORBA/IIOP
- open server/slim/conf/jboss-service.xml in the vi editor
- remove/comment the following XML fragments from the
from under the
<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"
MBean
<attribute name="RMI_IIOPService">jboss:service=CorbaORB</attribute>
If you removed the user-transaction-service.xml
- open server/slim/conf/jboss-service.xml in the vi editor
- remove/comment the following XML fragments from the
from under the
<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"
MBean
<attribute name="UserTransactionService">jboss:service=ClientUserTransaction</attribute>
If you do not need JSR-77 support (tried to make JBoss, Weblogic and Websphere support some basic similar JMX monitoring) you can remove/comment the entire fragment from server/slim/conf/jboss-service.xml:
<!-- ==================================================================== --> <!-- JSR-77 Single JBoss Server Management Domain --> <!-- ==================================================================== --> <mbean code="org.jboss.management.j2ee.LocalJBossServerDomain" name="jboss.management.local:j2eeType=J2EEDomain,name=Manager"> <attribute name="MainDeployer">jboss.system:service=MainDeployer</attribute> <attribute name="SARDeployer">jboss.system:service=ServiceDeployer</attribute> <!-- <attribute name="EARDeployer">jboss.j2ee:service=EARDeployer</attribute>--> <attribute name="EJBDeployer">jboss.ejb:service=EJBDeployer</attribute> <attribute name="RARDeployer">jboss.jca:service=RARDeployer</attribute> <attribute name="CMDeployer">jboss.jca:service=ConnectionFactoryDeployer</attribute> <attribute name="WARDeployer">jboss.web:service=WebServer</attribute> <attribute name="MailService">jboss:service=Mail</attribute> <!-- <attribute name="JMSService">jboss.mq:service=DestinationManager</attribute>--> <attribute name="JNDIService">jboss:service=Naming</attribute> <attribute name="JTAService">jboss:service=TransactionManager</attribute> <!-- <attribute name="UserTransactionService">jboss:service=ClientUserTransaction</attribute> <attribute name="RMI_IIOPService">jboss:service=CorbaORB</attribute>--> </mbean>
If you do not need client-side transaction management (remember that using this means you're a bad person)
- open server/slim/conf/jboss-service.xml in the vi editor
- remove/comment the following XML fragments
<!-- | UserTransaction support. --> <mbean code="org.jboss.tm.usertx.server.ClientUserTransactionService" name="jboss:service=ClientUserTransaction" xmbean-dd="resource:xmdesc/ClientUserTransaction-xmbean.xml"> <depends> <mbean code="org.jboss.invocation.jrmp.server.JRMPProxyFactory" name="jboss:service=proxyFactory,target=ClientUserTransactionFactory"> <attribute name="InvokerName">jboss:service=invoker,type=jrmp</attribute> <attribute name="TargetName">jboss:service=ClientUserTransaction</attribute> <attribute name="JndiName">UserTransactionSessionFactory</attribute> <attribute name="ExportedInterface"> org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory </attribute> <attribute name="ClientInterceptors"> <interceptors> <interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor> <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> </interceptors> </attribute> <depends>jboss:service=invoker,type=jrmp</depends> </mbean> </depends> <depends optional-attribute-name="TxProxyName"> <mbean code="org.jboss.invocation.jrmp.server.JRMPProxyFactory" name="jboss:service=proxyFactory,target=ClientUserTransaction"> <attribute name="InvokerName">jboss:service=invoker,type=jrmp</attribute> <attribute name="TargetName">jboss:service=ClientUserTransaction</attribute> <attribute name="JndiName"></attribute> <attribute name="ExportedInterface"> org.jboss.tm.usertx.interfaces.UserTransactionSession </attribute> <attribute name="ClientInterceptors"> <interceptors> <interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor> <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> </interceptors> </attribute> <depends>jboss:service=invoker,type=jrmp</depends> </mbean> </depends> </mbean>
- you can now remove server/slim/conf/xmdesc/ClientUserTransaction-xmbean.xml since its not referenced
if you do not need persistent MBean attributes (no JBoss MBeans use this by default...yet)
- open server/slim/conf/jboss-service.xml in the vi editor
- remove/comment this XML fragment
<!-- ==================================================================== --> <!-- XMBean Persistence --> <!-- ==================================================================== --> <mbean code="org.jboss.system.pm.AttributePersistenceService" name="jboss:service=AttributePersistenceService" xmbean-dd="resource:xmdesc/AttributePersistenceService-xmbean.xml"> <attribute name="AttributePersistenceManagerClass"> org.jboss.system.pm.XMLAttributePersistenceManager </attribute> <attribute name="AttributePersistenceManagerConfig"> <data-directory>data/xmbean-attrs</data-directory> </attribute> <attribute name="ApmDestroyOnServiceStop">false</attribute> <attribute name="VersionTag"></attribute> </mbean>
- you can also remove server/slim/conf/xmdec/xmdesc/AttributePersistenceService-xmbean.xml since it is no longer referenced
If you do not use RMI Classloading (for loading codebases from the client using the classes on the server)
- open server/slim/conf/jboss-service.xml in the vi editor
- remove/comment this XML fragment
<!-- ==================================================================== --> <!-- JBoss RMI Classloader - only install when available --> <!-- ==================================================================== --> <mbean code="org.jboss.util.property.jmx.SystemPropertyClassValue" name="jboss.rmi:type=RMIClassLoader"> <attribute name="Property">java.rmi.server.RMIClassLoaderSpi</attribute> <attribute name="ClassName">org.jboss.system.JBossRMIClassLoader</attribute> </mbean>
and
<!-- ==================================================================== -->
<!-- Class Loading -->
<!-- ==================================================================== -->
<mbean code="org.jboss.web.WebService"
name="jboss:service=WebService">
<attribute name="Port">8083</attribute>
<!-- Should resources and non-EJB classes be downloadable -->
<attribute name="DownloadServerClasses">true</attribute>
<attribute name="Host">${jboss.bind.address}</attribute>
<attribute name="BindAddress">${jboss.bind.address}</attribute>
</mbean>
- and change this XML fragment (NOTE: In JBoss 4.0, this is located in the file server/slim/deploy/ejb-deployer.xml):
<!-- EJB deployer, remove to disable EJB behavior--> <mbean code="org.jboss.ejb.EJBDeployer" name="jboss.ejb:service=EJBDeployer"> <attribute name="VerifyDeployments">true</attribute> ... <depends optional-attribute-name="WebServiceName">jboss:service=WebService</depends> </mbean>
to read like this:
<!-- EJB deployer, remove to disable EJB behavior--> <mbean code="org.jboss.ejb.EJBDeployer" name="jboss.ejb:service=EJBDeployer"> <attribute name="VerifyDeployments">true</attribute> ... <!-- <depends optional-attribute-name="WebServiceName">jboss:service=WebService</depends> --> </mbean>
or alternatively remove the WebServiceName? depends/attribute.
If you only want to use JBoss Naming locally (no RMI clients)
- open server/slim/conf/jboss-service.xml in vi
- change the following XML fragment
<!-- ==================================================================== --> <!-- JNDI --> <!-- ==================================================================== --> <mbean code="org.jboss.naming.NamingService" name="jboss:service=Naming" xmbean-dd="resource:xmdesc/NamingService-xmbean.xml"> ... <!-- The listening port for the bootstrap JNP service. Set this to -1 to run the NamingService without the JNP invoker listening port. --> <attribute name="Port">1099</attribute> ... <!-- The port of the RMI naming service, 0 == anonymous --> <attribute name="RmiPort">1098</attribute> ... </mbean>
To read
<!-- ==================================================================== --> <!-- JNDI --> <!-- ==================================================================== --> <mbean code="org.jboss.naming.NamingService" name="jboss:service=Naming" xmbean-dd="resource:xmdesc/NamingService-xmbean.xml"> ... <!-- The listening port for the bootstrap JNP service. Set this to -1 to run the NamingService without the JNP invoker listening port. --> <attribute name="Port">-1</attribute> ... <!-- The port of the RMI naming service, 0 == anonymous --> <attribute name="RmiPort">0</attribute> ... </mbean>
The RmiPort is mostly optional but it means we won't bind to 1098 so that can be helpful.
You may also want to remove the thread pool associated by removing this line from the same XML block:
<depends optional-attribute-name="LookupPool" proxy-type="attribute">jboss.system:service=ThreadPool</depends>
and the thread pool block itself:
<!-- A Thread pool service --> <mbean code="org.jboss.util.threadpool.BasicThreadPool" name="jboss.system:service=ThreadPool"> <attribute name="Name">JBoss System Threads</attribute> <attribute name="ThreadGroupName">System Threads</attribute> <attribute name="KeepAliveTime">60000</attribute> <attribute name="MinimumPoolSize">1</attribute> <attribute name="MaximumPoolSize">10</attribute> <attribute name="MaximumQueueSize">1000</attribute> <attribute name="BlockingMode">run</attribute> </mbean>
The JNDIView MBean (shows the JNDI naming tree) is increadibly useful from the JMX Console if you want to use it, but if you don't
- open server/slim/conf/jboss-service.xml in vi
- remove
<mbean code="org.jboss.naming.JNDIView" name="jboss:service=JNDIView" xmbean-dd="resource:xmdesc/JNDIView-xmbean.xml"> </mbean>
- you can also remove server/slim/conf/xmdesc/JNDIView-xmbean.xml
If you do not use JBossSX, our integrated JAAS-based security for EJBs or Web-tier components (then you deserve to be flogged and I hope you get hacked but thats another story):
- open server/slim/conf/jboss-service.xml in vi
- remove
<!-- ==================================================================== --> <!-- Security --> <!-- ==================================================================== --> <!-- <mbean code="org.jboss.security.plugins.SecurityConfig" name="jboss.security:service=SecurityConfig"> <attribute name="LoginConfig">jboss.security:service=XMLLoginConfig</attribute> </mbean> <mbean code="org.jboss.security.auth.login.XMLLoginConfig" name="jboss.security:service=XMLLoginConfig"> <attribute name="ConfigResource">login-config.xml</attribute> </mbean>
- edit server/slim/deploy/jbossweb-tomcatxx.sar/META-INF/jboss-service.xml and comment out these fragments:
<!-- The JAAS security domain to use in the absense of an explicit security-domain specification in the war WEB-INF/jboss-web.xml --> <!-- <attribute name="DefaultSecurityDomain">java:/jaas/other</attribute>-->
and
<!-- A mapping to the server security manager service which must be operation compatible with type org.jboss.security.plugins.JaasSecurityManagerServiceMBean. This is only needed if web applications are allowed to flush the security manager authentication cache when the web sessions invalidate. --> <!-- <depends optional-attribute-name="SecurityManagerService" proxy-type="attribute">jboss.security:service=JaasSecurityManager </depends>-->
- also remove/comment:
<!-- JAAS security manager and realm mapping --> <mbean code="org.jboss.security.plugins.JaasSecurityManagerService" name="jboss.security:service=JaasSecurityManager"> <attribute name="SecurityManagerClassName"> org.jboss.security.plugins.JaasSecurityManager </attribute> <attribute name="DefaultCacheTimeout">1800</attribute> <attribute name="DefaultCacheResolution">60</attribute> </mbean>
- If you're using JBossMQ you'll need to either remove (preferred) all test queues/topics from server/slim/deploy/jms/jbossmq-destinations-service.xml or comment out their security information. Add comments like the following if you choose to keep the example topics/queues:
<mbean code="org.jboss.mq.server.jmx.Topic" name="jboss.mq.destination:service=Topic,name=testTopic"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> <!-- <depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends> <attribute name="SecurityConf"> <security> <role name="guest" read="true" write="true"/> <role name="publisher" read="true" write="true" create="false"/> <role name="durpublisher" read="true" write="true" create="true"/> </security> </attribute>--> </mbean> <mbean code="org.jboss.mq.server.jmx.Topic" name="jboss.mq.destination:service=Topic,name=testTopic"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> <!-- <depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends> <attribute name="SecurityConf"> <security> <role name="guest" read="true" write="true"/> <role name="publisher" read="true" write="true" create="false"/> <role name="durpublisher" read="true" write="true" create="true"/> </security> </attribute>--> </mbean> <mbean code="org.jboss.mq.server.jmx.Topic" name="jboss.mq.destination:service=Topic,name=testDurableTopic"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> <!-- <depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends> <attribute name="SecurityConf"> <security> <role name="guest" read="true" write="true"/> <role name="publisher" read="true" write="true" create="false"/> <role name="durpublisher" read="true" write="true" create="true"/> </security> </attribute>--> </mbean> <mbean code="org.jboss.mq.server.jmx.Queue" name="jboss.mq.destination:service=Queue,name=testQueue"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> <!-- <depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends> <attribute name="SecurityConf"> <security> <role name="guest" read="true" write="true"/> <role name="publisher" read="true" write="true" create="false"/> <role name="noacc" read="false" write="false" create="false"/> </security> </attribute>--> </mbean>
- if using JBossMQ you'll also need to edit server/slim/deploy/jms/jbossmq-service.xml and change the InterceptorLoader? XML fragment to read like this:
<mbean code="org.jboss.mq.server.jmx.InterceptorLoader" name="jboss.mq:service=TracingInterceptor"> <attribute name="InterceptorClass">org.jboss.mq.server.TracingInterceptor</attribute> <depends optional-attribute-name="NextInterceptor">jboss.mq:service=DestinationManager</depends> <!-- <depends optional-attribute-name="NextInterceptor">jboss.mq:service=SecurityManager</depends> --> </mbean>
- you'll also need to comment out or remove (from server/slim/deploy/jms/jbossmq-service.xml):
<!-- <mbean code="org.jboss.mq.security.SecurityManager" name="jboss.mq:service=SecurityManager"> <attribute name="DefaultSecurityConfig"> <security> <role name="guest" read="true" write="true" create="true"/> </security> </attribute> <attribute name="SecurityDomain">java:/jaas/jbossmq</attribute> <depends optional-attribute-name="NextInterceptor">jboss.mq:service=DestinationManager</depends> </mbean> -->
- alter the dead letter queue entry (server/slim/deploy/jms/jbossmq-service.xml) by commenting out the security stuff:
<!-- Dead Letter Queue --> <mbean code="org.jboss.mq.server.jmx.Queue" name="jboss.mq.destination:service=Queue,name=DLQ"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> <!-- <depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends>--> </mbean>
- in server/slim/deploy/jms/jms-ds.xml alter the JmsXA entry to read as follows:
<!-- JMS XA Resource adapter, use this to get transacted JMS in beans --> <tx-connection-factory> <jndi-name>JmsXA</jndi-name> <xa-transaction/> <adapter-display-name>JMS Adapter</adapter-display-name> <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property> <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property> <max-pool-size>20</max-pool-size> <!-- <security-domain-and-application>JmsXARealm</security-domain-and-application>--> </tx-connection-factory>
- If using JBoss 4, also do this 2 things:
- in conf/login-config.xml, comment as follows:
<!-- Security domains for testing new jca framework <application-policy name = "HsqlDbRealm"> <authentication> <login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule" flag = "required"> <module-option name = "principal">sa</module-option> <module-option name = "userName">sa</module-option> <module-option name = "password"></module-option> <module-option name = "managedConnectionFactoryName"> jboss.jca:service=LocalTxCM,name=DefaultDS </module-option> </login-module> </authentication> </application-policy> <application-policy name = "JmsXARealm"> <authentication> <login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule" flag = "required"> <module-option name = "principal">guest</module-option> <module-option name = "userName">guest</module-option> <module-option name = "password">guest</module-option> <module-option name = "managedConnectionFactoryName"> jboss.jca:service=TxCM,name=JmsXA </module-option> </login-module> </authentication> </application-policy> -->
- and in deploy/hsqldb-ds.xml comment:
<!-- Use the security domain defined in conf/login-config.xml <security-domain>HsqlDbRealm</security-domain> -->
If you are not using the Pooled Invoker (see tuning section, you may want to use the pooled invoker) then:
- open server/slim/conf/jboss-service.xml in vi
- remove:
<!--
<mbean code="org.jboss.invocation.pooled.server.PooledInvoker"
name="jboss:service=invoker,type=pooled">
<attribute name="NumAcceptThreads">1</attribute>
<attribute name="MaxPoolSize">300</attribute>
<attribute name="ClientMaxPoolSize">300</attribute>
<attribute name="SocketTimeout">60000</attribute>
<attribute name="ServerBindAddress">${jboss.bind.address}</attribute>
<attribute name="ServerBindPort">4445</attribute>
<attribute name="ClientConnectAddress">${jboss.bind.address}</attribute>
<attribute name="ClientConnectPort">0</attribute>
<attribute name="EnableTcpNoDelay">false</attribute>
<depends optional-attribute-name="TransactionManagerService">
jboss:service=TransactionManager</depends>
</mbean>
If you do not wish to use the BeanShell deployer
- open server/slim/conf/jboss-service.xml in vi
- remove or comment
<mbean code="org.jboss.varia.deployment.BeanShellSubDeployer" name="jboss.scripts:service=BSHDeployer"> </mbean>
- remove server/slim/bsh* (bsh-deployer.jar, bsh-1.3.0.jar)
If you do not hot deploy files into the server/slim/deploy directory without restarting JBoss:
- open server/slim/conf/jboss-service.xml in vi
- change this XML frament:
<!-- An mbean for hot deployment/undeployment of archives. --> <mbean code="org.jboss.deployment.scanner.URLDeploymentScanner" name="jboss.deployment:type=DeploymentScanner,flavor=URL"> ... <attribute name="ScanPeriod">5000</attribute> ... </mbean>
to read (by adding):
<!-- An mbean for hot deployment/undeployment of archives. --> <mbean code="org.jboss.deployment.scanner.URLDeploymentScanner" name="jboss.deployment:type=DeploymentScanner,flavor=URL"> ... <attribute name="ScanPeriod">5000</attribute> <attribute name="ScanEnabled">False</attribute> ... </mbean>
- see the tuning section for other advice regarding this from a performance perspective
If you do not use clustering
- The best way to do this is to start from the "default" config rather than the "all" config. Then bring over from the "all" config any miscellaneous services that you are using that aren't in "default".
- If you must to start from the "all" config:
- Remove server/slim/farm
- Remove server/slim/deploy-hasingleton
- Remove server/slim/deploy/cluster-service.xml
- Remove server/slim/deploy/tc5-cluster-service.xml (OR server/slim/deploy/tc5-cluster.sar on 4.0.4 or later)
- Remove server/slim/deploy/deploy.last/farm-service.xml
- Remove server/slim/deploy/deploy-hasingleton-service.xml
- Go into the server/slim/deploy/jms folder, remove it's contents, and replace them with the contents of the server/default/deploy/jms folder.
- Edit server/slim/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml to remove this fragment:
<!-- Needed if using HTTP Session Clustering or if the ClusteredSingleSignOn valve is enabled in the tomcat server.xml file --> <depends>jboss.cache:service=TomcatClusteringCache</depends>
If you do not use distributed (clustered) web sessions
- Remove server/slim/deploy/tc5-cluster-service.xml (OR server/slim/deploy/tc5-cluster.sar on 4.0.4 or later)
- Edit server/slim/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml to remove this fragment:
<!-- Needed if using HTTP Session Clustering or if the ClusteredSingleSignOn valve is enabled in the tomcat server.xml file --> <depends>jboss.cache:service=TomcatClusteringCache</depends>
If you do not use the Farm service (replicated deployments)
- Remove server/slim/farm
- Remove server/slim/deploy/deploy.last/farm-service.xml
Click here for a complete list of service dependencies.
]]>
榪欎嬌寰桱Boss姣忓鍔犱竴涓嚎紼嬶紙thread)灝變細绔嬪嵆娑堣?5M鍐呭瓨錛岃屾渶浣沖煎簲璇ユ槸128K,榛樿鍊煎ソ鍍忔槸512k.
榪欏氨鏄疛Boss鍒氬惎鍔ㄦ椂錛岃繕鏈?00Mb鍐呭瓨瀵屼綑錛屼絾浼氬湪涓涓皬鏃跺唴榪呴熺敤瀹岋紝鍥犱負鏈嶅姟鍣ㄧ殑threads鍦ㄨ繀閫熷鍔犮傚墠3澶╋紝姣忓ぉ閮藉鍚?0Mb宸﹀彸鐨剆wap.鍦ㄧ鍥涘ぉ寮濮嬬ǔ瀹氫笅鏉ャ備粖騫存槬鑺傚湪澶栧害鍋囷紝瑙傚療鍒頒簡榪欎釜鐜拌薄錛屽嵈涓嶇悊瑙ｅ叾鍘熷洜錛氭湇鍔″櫒鍦ㄧ嚎紼嬪埌杈?00涔嬪悗錛屼竴鑸笉鍐嶅鍔犳柊鐨勭嚎紼嬶紝鏂板鍔犵殑鍦ㄧ敤瀹屼箣鍚庯紝浼氳榪呴焏estroy錛?願昏鐜摢璇栧瑝涓嶅帴妯熸仌錛茶櫦鑰嶎儘鏃佽瘱鑸皠璇╂磳顑旈剟鏂撴顠曡】楂?1.25-2.10鎵浣跨敤鐨勭嚎紼嬪熀鏈槸1.21-1.23鍒涘緩鐨勶紝鍥犳娌℃湁鍐嶆秷鑰楁柊鐨勫唴瀛樸傛湇鍔″櫒鎸佺畫榪愯鏃墮棿錛屼篃鍥犳澶уぇ瓚呬箮鎴?澶╃殑棰勬湡錛屽埌杈句簡20澶┿?br>鏄ㄥぉ鎵浣滅殑淇敼錛?br>1.淇敼JAVA_OPTS,鍘繪帀+XX:AggressiveHeap錛屼慨鏀筙ss銆傜幇鍦ㄧ殑JAVA_OPTS涓猴細
錛峏ms 520m -Xmx 900m -Xss 128k
2.淇敼deploy/jbossweb-tomcat55.sar/service.xml
灝唌axThreads鏍規嵁鐩墠鐨勮闂噺鐢遍粯璁ょ殑250闄嶄負75錛屽茍浣跨敤jboss 4榛樿鏈啓鍦ㄦ爣鍑唖ervice.xml閲岄潰鑰宩boss 3鍐欏叆浜嗙殑2涓弬鏁? maxSparseThreads=55錛宮inSparseThreads=25
3.淇敼浜唎racle-ds.xml灝嗘渶澶ц繛鎺ユ暟鏈?50闄嶄負50.
4.鍘繪帀浜嗕竴浜涗笉鐢ㄧ殑鏈嶅姟
]]>