Chapter 11 Performance Tuning

You can address any of currently faced or anticipated performance issues by doing performance tuning for the following:

• Database

• Application Server

• Thread Pools

• MySQL Database Connections

• Clustering

• Memory

• Properties File Changes

• Servlet Filters

• Portlets

• Java Environment

• Portal Extensions

Database

If you are using the MySQL database, you need to configure the my.cnf file. The following are some of the important variables in the my.cnf file.

• query_cache_size

  In a situation where the database has to repeatedly run the same queries on the same data set, returning the same results each time, MySQL can cache the result set, avoiding the overhead of running through the data over and over and is extremely helpful on busy servers.

• key_buffer_size

  The value of key_buffer_size is the size of the buffer used with indexes. The larger the buffer, the faster the SQL command finishes and a result is returned. The rule-of-thumb is to set the key_buffer_size to at least a quarter, but no more than half, of the total amount of memory on the server. Ideally, it will be large enough to contain all the indexes (the total size of all .MYI files on the server).

  A simple way to check the actual performance of the buffer is to examine four additional variables: key_read_requests, key_reads, key_write_requests, and key_writes.

  • If you divide the value of key_read by the value of key_reads_requests, the result should be less than 0.01. Also, if you divide the value of key_write by the value of key_writes_requests, the result should be less than 1.

• table_cache

  The default is 64. Each time MySQL accesses a table, it places it in the cache. If the system accesses many tables, it is faster to have these in the cache. MySQL, being multi-threaded, may be running many queries on a table at a time, and each of these opens a table. Examine the value of open_tables at peak times. If you find that it stays at the same value as your table_cache value, and then the number of opened_tables starts increasing rapidly, you should increase the table_cache if you have enough memory.

• sort_buffer

  The sort_buffer is very useful for speeding up myisamchk operations (which is why it is set much higher for that purpose in the default configuration files), but it can also be useful everyday when performing large numbers of sorts.

• read_rnd_buffer_size

  The read_rnd_buffer_size is used after a sort, when reading rows in sorted order. If you use many queries with ORDER BY, upping this can improve performance. Remember that, unlike key_buffer_size and table_cache, this buffer is allocated for each thread. This variable was renamed from record_rnd_buffer in MySQL 4.0.3. It defaults to the same size as the read_buffer_size. A rule-of-thumb is to allocate 1KB, for each 1MB of memory on the server, for example 1MB on a machine with 1GB memory.

• thread_cache

  If you have a busy server getting a lot of quick connections, set your thread cache high enough that the Threads_created value in SHOW STATUS stops increasing. This should take some of the load off of the CPU.

• tmp_table_size

  "Created_tmp_disk_tables" are the number of implicit temporary tables on disk created while executing statements and "created_tmp_tables" are memory-based. Obviously it is bad if you have to go to disk instead of memory all the time.

Application Server

Tuning the Application Server is most important to see 'real' performance improvement.

For tuning GlassFish see, Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide.

Thread Pools

For the details of thread pooling in GlassFish, see the chapter on Thread Pooling in Sun GlassFish Enterprise Server 2.1 Administration Guide.

MySQL Database Connections

For tuning MySQL database connections, you can refer MySQL Documentation.

Clustering

Clustering is needed for scalability, increased availability, and load balancing.

If you are using Sun GlassFish Enterprise Server as the application server, you can refer to the following links for the information on clustering:

• http://developers.sun.com/appserver/reference/techart/glassfishcluster/

• https://glassfish.dev.java.net/javaee5/build/GlassFish_LB_Cluster.html

• http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV2Architecture

• http://docs.sun.com/app/docs/prod/gf.entsvr.v3pre?l=en&a=view

Memory

Memory is one of the first things to look at when you want to optimize performance. If you have any disk swapping, that will have a serious impact on performance. Make sure that your server has an optimal amount of memory and that your JVM is tuned to use it.

There are three JVM command switches that control the amount of memory it uses.

Java heap size:

-Xms

VM heap size:

-Xmx

PermGen space:

-XX:MaxPermSize

These three settings control the amount of memory available to the JVM initially, the maximum amount of memory into which the JVM can grow, and the separate area of the heap called Permanent Generation space.

For example, the default settings can be:

-Xms128m -Xmx1024m -XX:MaxPermSize=128m

This is perfectly reasonable for a moderately sized machine or a developer machine. These settings allow the JVM to initially take 128MB of RAM, grow up to 1024MB of RAM, and have a PermGen space of 128MB. If, however, you have Web Space Server on a server with 4GB of RAM and you are having performance problems, the first thing you might want to look at is increasing the memory available to the JVM. You will be able to tell if memory is a problem by running a profiler (such as Jprobe or YourKit) on the server. If you see Garbage Collection (GC) running frequently, you will definitely want to increase the amount of memory available to the JVM.

Issues with PermGen space can also affect performance. PermGen space contains long-lived classes, anonymous classes and interned Strings. Hibernate, in particular-which Web Space Server uses extensively has been known to make use of PermGen space. If you increase the amount of memory available to the JVM, you may want to increase the amount of PermGen space accordingly.

Properties File Changes

There are also some changes you can make to your portal-ext.properties file once you are in a production environment.

Set the following to false to disable checking the last modified date on server side CSS and JavaScript:

last.modified.check=false

Set this property to true to load the theme's merged CSS files for faster loading for production. By default, it is set to false for easier debugging for development. You can also disable fast loading by setting the URL parameter css_fast_load to 0.

theme.css.fast.load=true

Set this property to true to load the combined JavaScript files from the property javascript.files into one compacted file for faster loading for production. By default, it is set to false for easier debugging for development. You can also disable fast loading by setting the URL parameter js_fast_load to 0.

javascript.fast.load=true

Also, set the following parameters:

portlet.css.enabled=false

velocity.engine.resource.manager.cache.enabled=true

com.liferay.portal.servlet.filters.layoutcache.LayoutCacheFilter=true

Servlet Filters

Web Space Server comes by default with a number of servlet filters enabled and running. It is likely that for your installation, you don't need them all. Two filters that you can disable without any impact are the Compression Filter and the Strip Filter. These filters are responsible for shrinking the size of the response (to save bandwidth). The Strip Filter removes whitespace from the response object, and the Compression Filter compresses it. This obviously requires some processing, and so disabling these two filters can enhance performance.

To disable a servlet filter, simply comment it out of your web.xml file.

If there is a feature supported by a servlet filter that you know you are not using, you can comment it out as well to achieve some performance gains. For example, if you are not using CAS for single sign-on, comment out the CAS Filter. If you are not using NTLM for single sign-ons, comment out the Ntlm Filter. If you are not using the Virtual Hosting for Communities feature, comment out the Virtual Host Filter. The fewer servlet filters you are running, the less processing power is needed for each request.

Portlets

Web Space Server comes pre-bundled with many portlets which contain a lot of functionality, but not every web site that is running on Web Space Server needs to use them all. In portlet.xml and liferay-portlet.xml, comment out the ones you are not using. While having a loan calculator, analog clock, or game of hangman available for your users to add to pages is nice, those portlets may be taking up resources that are needed by custom portlets you have written for your site. If you are having performance problems, commenting out some of the unused portlets may give you the performance boost you need.

Java Environment

The following are the links for articles and white papers on tuning Java Runtime Environment.

• http://java.sun.com/performance/reference/whitepapers/tuning.html

• http://www.javaperformancetuning.com/

Portal Extensions

Some changes to the portal-ext.properties file can boost the performance of Sun GlassFish Web Space Server.