The follow are recommended performance tuning tips for MapXtreme Java: Use zoom layering: The #1 performance improvement is to use zoom layer settings to display layer detail only when zoomed in. Minimize the use of fancy feature and label styles: Map composition affects performance. Maps with more labels, and maps with lots of intricately styled lines (e.g., railroads) take longer to render. Consider including only the necessary level of detail on the map. Use connection pooling when accessing RDBMS tables.  Use thick drivers when accessing Oracle8i data. Pool MapJ objects that are pre-loaded with a geoset/mdf in the middle-tier for 3-tier applications.  Set appropriate coordinate system type for the task: To optimize image rendering, set the display coordinate system to the one that is used by most of the layer data. To optimize raw data access, set the numeric coordinate system to the coordinate system that most of the layer data is in. The numeric coordinate system is used for all numerical data associated with MapJ, such as the bounds, zoom, and center. Use appropriate image format: Use GIF format with the video card depth set to 256 colors for image export. Use PNG or JPEG if images needed require more than 256 colors (e.g. images that include raster layers). Choose to stream images over writing to disk: Streaming images directly back to clients is usually faster than writing the images to disk on the server; however it does depend on specific application server and network latency issues. Put map data in memory (UNIX platforms).  Application server performance tuning options: Pay attention to options such as thread pooling that may be available in the application server. Check the version of the Java VM: Different versions behave differently. For example, iPlanet Web Server 4 performs better with the VM that comes with it (1.2.2) than with the newer Java 1.3 VM. Note: MapXtreme Java Edition requires Java 1.2.2 or later. Try different VM's: The latest may not always be the fastest. Sun's Java HotSpot server is usually fastest. IBM's JVM is also fast. HotSpot Server VM: The VM may be capable of running in different modes, such as "classic," "HotSpot[tm] server," and "HotSpot client." Try running MapXtreme Java Edition with the VM set to run as HotSpot server. To see what mode the VM is running in, type: java -version on a command line. To force the VM to use hotspot server mode, it may be necessary to add the option "-server" to the Java command line that is used to start the servlet container. For example:  java -server -version  Depending on the VM, it may be possible to run a "set_default_vm" executable to configure Java to use HotSpot Server mode by default, even when the "-server" argument is omitted from the command line. Some servers, such as ServletExec, allow the selection of HotSpot Server from within the Administrator page.  Note that a standard Java installation has separate directories (under jdk/jre/bin) for classic, hotspot and server. On Windows, for example, these directories contain different DLLs. Depending on what server is being used, it may be necessary to update the server configuration to look in the "server" directory before the server will use HotSpot Server; for example, if configuring Tomcat to run using JNI, it may be necessary to edit the worker.jni.jvn_lib setting in jni-workers.properties to point to the library in the server directory.  Pay attention to VM settings like initial and maximum heap size: Some servers allow configuring these heap sizes through an Administrator page. If it isn't possible to set the heap sizes through the Administrator, it may be necessary to edit the java command line used to start the servlet container. For example, the following partial command line sets a starting heap size of 32 MB, and a maximum heap size of 256 MB:  java -Xms32m -Xmx256m  How to determine JVM heap size: -mx, -ms [-Xmx, -Xms]. As a starting point for a server based on a single JVM, consider setting the maximum heap size to 1/4 the total physical memory on the server and setting the minimum to 1/2 of the maximum heap. Sun recommends that ms be set to somewhere between 1/10 and 1/4 of the mx setting. They do not recommend setting ms and mx to be the same. Bigger is not always better for heap size. In general increasing the size of the Java heap improves throughput to the point where the heap no longer resides in physical memory. Once the heap begins swapping to disk, Java performance drastically suffers. Therefore, the mx heap setting should be set small enough to contain the heap within physical memory. Also, large heaps can take several seconds to fill up, so garbage collection occurs less frequently which means that pause times due to GC will increase. Use verbose:gc to help determine the optimum size that minimizes overall GC. Use a dedicated web server: Take advantage of a dedicated web server instead of using a servlet container as the web server. Some servlet containers, such as Tomcat, can service both servlet requests and web server requests. However, it is preferable to use a dedicated web server, such as Apache, for web server requests, so that Tomcat is used only as a servlet container. The Tomcat installation contains HTML files describing how to integrate Apache and Tomcat.  Use multiple instances of Tomcat: If using Tomcat as the servlet container, it may be necessary to set up multiple instances of Tomcat. On some Solaris servers with 4 or more CPUs, MapXtreme's performance improves when there are three instances of Tomcat running concurrently. For example, the server might run Apache and three Tomcat instances, and the Tomcat setup (e.g. mod-jk.conf) can perform load balancing among the Tomcat instances.  If there are multiple Tomcat instances on the same computer, it will be necessary to modify the Tomcat configuration, so that each instance listens on a different port number. For example, it may be desired to have multiple copies of the server.xml file (e.g. server2.xml, server3.xml) each of which designates a unique port number and a unique workDir setting, so that the multiple Tomcat instances do not conflict. It will also be necessary to start each Tomcat instance with the optional -f argument, to designate which xml file it is desired to use. For example:  tomcat start -f ../conf/server2.xml  Note that load balancing is not necessarily limited to one computer. For example, Tomcat may be running on several computers, with Apache performing load balancing.  Turn off dynamic class loading in your servlet container: Some servlet containers can be configured so that they automatically reload servlet class files whenever the class files change (e.g. whenever a servlet is recompiled). This dynamic reloading is useful when developing or debugging a servlet, because it is possible to recompile and see the changes immediately, without restarting the servlet container. However, dynamic class reloading hurts performance, so it may be necessary to disable class reloading when deploying a production server. For example, Tomcat's server.xml file has a "reloadable" setting for each context.  Allow enough warm-up time. If performing timing tests on the servlet container, be aware that the first requests will take longer, as the VM loads the necessary classes. Subsequent requests are faster. The amount of time required to "warm up" the server depends in part on whether HotSpot Server has been configured. To achieve the most accurate timing test results, the servlet container to should be warmed up for several minutes (several minutes of servicing a stream of requests).  Limit logging information: For production servers and performance tests, try configuring the servlet container to output less debugging information to log files. For example, Tomcat's logging is configured via the server.xml file. Avoid I/O conflicts: Put HTML content and HTTP logs on different disks, so they are not in I/O conflict, but rather work in parallel. Placing map files on a separate disk is also a good idea. Mount file system as Read Only: On Solaris systems, use the -noatime switch when mounting the file system where the tab files reside. Using this switch forces read only and may produce faster disk reads.