This one is being presented by Andy Miller, VP of Engineering. Trying to do performance tuning in a very short time frame.
Agenda performance tuning basics, EAP tuning, Linux specific tuning, database and storage performance tuning, performance tuning as applied to an actual EJB 3 application.
Performance Tuning Basics - Understand your performance requirements. If this is replacing an existing system then look at that system's usage. If this is a new system, then understand expected usage scenarios. In either case, need to understand the peak time periods an how that will differ from non-peak times. Focus on peak usage, not averages.
Instrumentation - Applications need to be instrumented for performance analysis. Without instrumentation, you don't have data to work with. Use asynchronous logging. Wrap debug log statements with if(debugEnabled()). This is more efficient than just using log.debug(). For example, if a string is being build in a log.debug() statement, the string will still be created even if the logging level is set above debug. This can cause the creation of a lot of unnecessary temporary Strings.
Understand where time is being spent in the application. Need to know where time is being spent in various transactions. Avoid the "shotgun method" of performance tuning. You can spread performance tuning all over the place, but without supporting performance data, you will likely not hit the real performance bottlenecks.
Connection Pooling. Database connection pooling are expensive to setup and tear down.. The EAP has robust connection pooling, and yo should monitor your connection usage from the database to determine proper sizing. Too small a pool will also throttle the application as the EAP will queue the request for a default of 30,000 milliseconds before giving up and throwing an exception. You can monitor the connection pool from the JMX Console.
Thread Pooling - The EAP has robust thread pooling, that should be sized appropriately. The EAP server has a file called jboss-service.xml in the conf directory that defines the system thread pool. In server.xml of the JBoss Web, there is a maxThreads setting.
Logging - The default configuration is that the console log is turned on. Very good for developers, but very bad for production. The JBoss log4j configuration (jboss-log4j.xml in the conf directory) will hot deploy.
Caching - JBoss Cache is an integral part of the EAP and can be sued directly by your application to cache anything you want. By far, one of the easiest potential performance enhancements you can make is caching of EJB 3 entities. You simply define what entities you want cached in the persistence.xml that you deploy with your EJB 3 application. Warnings - review the cache eviction policy and the overall memory space your cache will take.
Clustering and Replication - Use buddy replication. Configure buddy replication in the jboss-service.xml that is in the server/
/deploy/jboss-web-cluster.sar/META-INF.
