Tuesday Oct 09, 2007

UltraSPARC T2 and WebSphere Application Server

As Sun continue to provide breakthrough multi-core technology and systems based on that you are going to have your hands on this new cool server very soon. As you already may know that its predecessor(Sun Fire T2000) has established itself as the best J2EE App Server Platform (In fact it dominates the other area too but I will leave that to my colleagues to comments on). The details from SPEC web-site are here for your reference:
BEA WebLogic Server SPECjAppServer2004 result on Sun Fire T2000
IBM WebSphere Application Server SPECjAppServer2004 result on Sun Fire T2000
Oracle Application Server SPECjAppServer2004 result on Sun Fire T2000
Sun Java Application Server SPECjAppServer2004 result on Sun Fire T2000

Now you are going to see the next generation server named Sun SPARC Enterprise T5120/T5220 and this is going to continue to lead this segment and other as well. Don't forget to check this blog.

So coming to the point I got my hands on one of these system and did some performance study of WebSphere Application Server V 6.1 and I found these systems to be very impressive. The results of our tests shows that it can give you double the performance of T2000. Due to limitation of 4GB of address space for 32-bit process and the App Server's own scalability, I think none of the App Server will be able to scale and fully utilize this system. So I used multiple instance to maximize the system usages. As the software remains the same the tuning and tuning recommendations are not going to change.

Here is what I have done with my WebSphere Application Server to get best out of this system:

Thread Pools:
ORB: 39/39
Web Container: 47/47
Default: 20/20

EJB Cache: 60000 (previously recommended setting on my blog would be ok too).

JVM Settings:
Heap : 2300-2600
-server -XX:NewSize/-XX:MaxNewSize 1/3rd of Heap
-Xss128k -XX:LargePageSizeInBytes=256m -XX:+AggressiveOpts
-XX:+UnlockDiagnosticVMOptions -XX:-EliminateZeroing -XX:+UseParallelGC
-XX:ParallelGCThreads=16 -XX:+UseParallelOldGC

Connection Pool:
Min/Max Connection: 160/160
Statement Cache: 120

Then the usual stuff we do with TCP Connection settings, disabling the performance monitoring framework, setting the keep-alive etc.

Here are few of the setting I put in my /etc/system and which helped a lot for network performance and interrupts distribution:
set ip:ip_soft_rings_cnt = 8
set ddi_msix_alloc_limit = 8

Some of the issues I came across and you should also keep an eye on that:
Use intrstat(1M) and mpstat(1M) to find out how the interrupts processing going on. intrstat will give you the interrupts processing for different devices and which core is handling that and then you can look at the mpstat(btw this is very long so redirect to some files to take a look at it later) which will tell you if it is a bottleneck.
DB Connection – They always originates from whatever is returned by gethostbyname(3NSL) API and thus it may become bottleneck. So I used containers so the result of these API call are different i.e that will hostname(1) of your zone.
Full GC – Keep an eye on full GC and set the New Generation appropriately.

Note: If you are looking for more information on UltraSPARC T2 don't forget to check http://blogs.sun.com/.

Disclosure Statement:
SPEC, SPECjAppServer2004 are reg tm of Standard Performance Evaluation Corporation. Links are from www.spec.org.

Friday Jun 22, 2007

Using Sun Java System Web Server V7.0 with WebSphere Application Server

As you already know that WebSphere Application Server support different version of Sun Java System Web Server.
Sometime back Version 7.0 has been released and it also works fine with different versions of WebSphere Application Server.
When you install the plugin here are the action that take place:

  • Lays out the binary
  • Installs the GSKit component
  • Generates the plugin_cfg.xml config file
  • Registers this plugin with the Sun Java System Web Server which means adding few lines to magnus.con and commenting two lines in obj.conf and adding two lines. This is what makes the Web Server during startup to load the plugin.

Here you can find the list of changes to configuration files when you upgrade from Version 6.X to Version 7.0 fi you are wondering what has been changed.
Once this is done your web-server is ready to route your request to your app server. There's a migration wizard as well if you want to migrate your previous version of web server to this version. If you don't want to re-install the plugin and get it migrated to new web-server here is a short cut for you:

  • Go to the config directory of Sun Java System Web Server 7.0 e.g /export/sun/webserver7/https-webserver7-host/config
  • Open the file maguns.conf in any editor eg vi
  • add this line to end of file: Init fn="as_init" bootstrap.properties="/export/IBM/WebSphere/Plugins/config/web
    server1/plugin-cfg.xml". This can be copied from previous magnus.conf file.
  • Save and quit the editor.
  • Now open the file: obj.conf and comments these tow lines:
    NameTrans fn="ntrans-j2ee" name="j2ee"
    Error fn="error-j2ee"
  • Add the following lines right after :
    Service fn="as_handler"
    AddLog fn="as_term"

    Restart the web-server and now you should be passsing the request to the app server.

    Thursday Jun 21, 2007

    SMF and WebSphere

    During discussion with one of the customer we found that there are interests around SMF for WebSphere. Taking this opportunity my friend Albert Leigh has already posted a head start and important link to get you started.

    Basic idea of SMF has been presented and it may need cover the complex scenario which I think wouldn't be a big deal to follow as long as you know what are the activity and its dependencies are to get started.

    Specially the thing are much straightforward when you plan to do things with standalone application server. The complexity arises when you go to multiple instance scenarios and you have clustering/distribution enabled. In these cases you have to take care of order in which you start the app eg. Node Manager must be started before you try to start the app server and thing like that.
    Same goes for the Web Server which has been configured through the admin interface and eligible to get started or stopped from single point of management.

    Let us know what else would you like to be done using SMF which is not just easy enough for yourself to do it. We will try to put the script to help you out.

    Wednesday Apr 18, 2007

    Class Data Sharing(CDS) with WebSphere on Solaris

    J2SE 5.0 has introduced lot of new features and one of them happens to be CDS which is supposed to help application startup(obviously making it faster to start) and use less memory(reduce memory footprint). This was available J2SE 5.0 or JDK 1.5. But when enabling this feature with WebSphere Application Server(WAS) it used to fail for following reasons:
    There was a hard set limitation on the JDK it was refusing to use this feature if there are more than 8 jar files in bootclasspath. The JDK which comes with WAS happened to have more than 8 classes and this wasn't usable.

    IBM has released a WAS fixpack which addresses this issue. You can download this JDK fixpack from here and remember you need to apply just the SDK fixpack to get this feature working for you. But in case if you would like to fix other issues which has been fixed in WAS then its good idea to get the whole fixpack which can be downloaded from WAS V6.1 Fix Pack 7 for Solaris.

    To enable your WAS installation to make use of this feature you need to have this JVM option added to you generic JVM argument:
    Which can turned off by -Xshare:off or -Xshare:auto enable class data sharing whenever possible.
    Another important thing to note here that this feature in JDK 1.5 has been made available to client VM only so you need to have "-client" option as well for genericJvmArguments. Because on ergonomics is going to start the server vm if it gets classified as server class machine.

    Thursday Apr 12, 2007

    WebSphere JVM/JDK on Solaris

    I have seen people getting confused about the version of Java Development Kit(JDK) with WebSphere Application Server (WAS) on Solaris.
    Here is the details:
    So far all the versions of WAS available on Solaris uses Sun JDK. Then you might be wondering why java -version output is something like this:

    Java(TM) 2 Runtime Environment, Standard Edition (IBM build 1.5.0_06-erdist-2006 0404 20060511)
    Java HotSpot(TM) Server VM (build 1.5.0_06-erdist-20060404, mixed mode)
    IBM Java ORB build orb50-20060511a (SR2)
    XML build XSLT4J Java 2.7.4
    XML build IBM JAXP 1.3.5
    XML build XML4J 4.4.5

    This tells us that this particular version of java is equivalent to 1.5.0_06 version of Sun's JDK. However there are pieces that has been either changed or modified some of them you can make out from above and they are:

    • ORB has been replaced with something which comes from IBM SR2 release at the same level.
    • For XML you can see various package has been replaced and I think names are quite descriptive and they have version information with them.
    • Security Frameowrk

    All of the above has been replaced by IBM implementation.

    More details you can find in your WAS/Java install dir(/opt/IBM/WebSphere/AppServer/java) and the files to look for are:

    • README_FIRST - Gives you all the information about the changes and known problems.
    • ibmorbguide.htm - Gives you ORB details.
    • securityguide.ref.htm - All the information about security implementation.

    Now the question is can this JVM is upgraded using Sun JVM - As far as I understand all the updates to JVM/JDK comes as fix packs from IBM so if you violate that then support may not be available so it's not good idea to do that.
    Of course, you are free to do whatever you want if you understand the pieces and ready to be on your own. You can replace and test with new version of libjvm.so or upgrade your JVM to higher version but making sure that the pieces that has been changed is incorporated following the docs I pointed out. But if you run into any problem you must figure out yourself because it is not supported and even if it works its not good idea for anything other than testing.

    Tuesday Mar 27, 2007

    GSKit 7 on Soalris 10

    Global Security Kit (GSKit) which is part of the supplement CD which comes with WebSphere Application Server(WAS) ND V6.1 and is a C API that is internal to IBM it is not available as seperate entity. There is not much distinct document exists for this API. It is the crypto-engine for many IBM software products including following
    IBM Tivoli Access Manager
    IBM HTTP Server (IHS)
    IBM MQseries

    Why do we need GSKit for App/Web Server ?
    GSKit allows an application to be SSL enabled and lets you to access SSL and TLS functions from your socket application program.
    You will need GSKit in Application Server based deployment if you intend to do the following:

    • SSL between client (browser) and IBM HTTP Server.

    • SSL between the IBM HTTP Server plug-in and WebSphere Application Server.

    • SSL between IBM HTTP Server and LDAP server.

    However when you install the HTTP server or WAS the GSKit never gets installed. This is part of the Web-Server plugin install. In other cases you have to do the install manually. There is also no uninstaller for GSKit as IBM just provides the installer.
    During the installation of GSKit it does following activity which requires that you must be a root user:

    • Installation/Registration of GSKit as solaris packages

    • Soft links in /usr/bin so you default executable search path has access to all the executable as part of the GSKit.

    • Soft links in /usr/lib so your default library search path has access to all the shared libaries of GSKit.

    None of this would be needed if the software that requires access to either the shared libraries or binaries can handle their own requirement by having their LD_LIBARY_PATH and PATH variable modified suitably, but which doesn't seems to be true in this case so it is available to everybody on the system. As you already know anything under /usr/bin is accessible to everyone on the system and then /usr/lib is included as default library serach path for evryone. This poses further restriction when you take it to zones/container where you must have the links laid out before you proceed this so you must do this in global zone before
    doing GSKit install in local zones. From local zones you cannot have write permission on these two directory. Not having the write permission will not allow you to create the soft links. When you do the GSKit install in global zone then the links are laid out for particular version of GSKit in /usr/lib and /usr/bin and then when you install in local zones all the soft links becomes valid as they will be pointing to right binaries in local zones install. Another thing to note here is that you cannot chnage the location of the install.

    Thursday Feb 01, 2007

    WebSphere v6.1 tuning simplified on Solaris 10

    I have been working on some simplification for the WebSphere App Server V6.1 performance tuning on Solaris 10 platform and it came to my attention that instead of playing with too many flags there is only one flag should be more than good enough to give the boost needed for performance. However this may not apply to all the work load but I would rather try and determine that and start overriding some of the defaults:

    Previously the tuning knobs of interest used to be like following:

    • initialHeapSize= eg. 2048
    • maximumHeapSize= eg. 2048
    • -server
    • -Xmn1024m At least 50% of the heap size; more may be better
    • -XX:-ScavengeBeforeFullGC
    • -XX:MaxTenuringThreshold=
    • -XX:+UseParallelGC
    • -XX:ParallelGCThreads= either equal to number of cpu or on multi core systems set it to somewhere between .5-1xNumber of cores.
    • -XX:+AggressiveHeap
    • -XX:PermSize=
    • -XX:+UseParallelOldGC

    All of this can be reduced to just couple of flags and it will give more throughput than this one:
    So the new reccomendations are:

    • initialHeapSize= eg. 2048
    • maximumHeapSize= eg. 2048
    • -server May not be needed in most cases
    • -XX:+AggressiveOpts -XX:+UnlockDiagnosticVMOptions -XX:-EliminateZeroing

    This will take care of JVM tuning and you should spend time setting the websphere thread pools right.
    Let me know if you find it other way...

    Wednesday Jan 10, 2007

    WebSphere Application Server (WAS) packaging on different Solaris platform

    By this time you may be already aware that WebSphere Application Server(WAS) 6.0.2.X and beyond is available on Solaris 10 which gives you flexibility to exploit the greatest operating system with different kind of h/w eg. SPRAC, AMD . There are few enhancement which has been done to improve the packaging of WebSphere Software. Going forward may be this is the way WebSphere sofware will be packaged:
    V6.1 of WebSphere Application Server has introduced the concept of non-root installer on Solaris platform and I think that's a good decision the IBM engineering has taken so you don't have to give the root privilages to WAS administartors.
    Here I will try to explain what are the differences you will notice due to this changes:

    • When you use the root installer the installation will add the WAS software as Solaris packages which will make an entry into operating system registery.

    • When you use the non-root installer it will not add the Solaris packages

    However for Solaris x64 processor-based systems WebSphere has taken this to another level and wether you use the root or non-root installer it won't add any packages to the Solaris package registery. Which I think is a very feature for people doing some engineering work and does the install/uninstall many times. During uninstallation if the package removal fails for some reason then you have to go to package registry and do some work to clean the system called manual uninstallation. But in the cases like no package registery you can simply delete the directory and remove the appropriate installation specific information which is usually found in the home directory of the user with which the WAS was installed eg ~/.ibm. You can also use installRegistryUtils also to find out the registry information.

    Tuesday Nov 14, 2006

    Using Sun Studio with WebSphere Application Server

    Profiling WebSphere Servers Using Sun Studio Performance Tools

    This page describes profiling servers being run under IBM's WebSphere Application Server system with the Sun Studio Performance Tools.

    To profile WebSphere Application Server(WAS), you will need to have a release of the Sun Studio Performance Tools, picked from the release list, properly installed and configured.
    All uses of the Sun Studio Performance Tools require a supported version of Solaris including any required patches. They also need a supported version of Java installed which can be used from WAS installation, this is bundeled and gets installed with WAS. Running the collect command with no arguments will run a script that will verify that all the appropriate patches are installed.
    A server run under IBM's WebSphere is written in Java; (see "Profiling Java Applications"). A server is launched by running a script which invokes the JVM to run it. To profile a server, you must ensure that the JVM command launching the server is prepended with a collect command, with appropriate arguments, to invoke the Sun Studio Collector. In the discussion below, the shell variable ${COLLECTOR} is used to refer to that command and arguments.

    In the next section, we describe setting ${COLLECTOR}, that is, determining the data collection options you will want to use. In the following section we describe the scripts used to launch a server, and how to edit them to insert ${COLLECTOR}. In the third section, we describe navigating through the measured performance data. In the last section, we give links to the IBM WebSphere documentation.

    Data Collection Options
    This section describes the setting of collection options for profiling, that is determining what to use for ${COLLECTOR} in WebSphere startup scripts.

    Data Options
    The command collect is the first token in the ${COLLECTOR}
    variable. You may be specify it either as an absolute path to wherever you have installed the tools, or as the command name only, provided you have set your path to include the installation.
    The default experiment is a clock-profiling experiment. You may also use hardware counter profiling or sychronization tracing. The experiment begins when the server is launched, and terminates when the server exits. If the profiling session is longer than about 20 minutes, low-resolution profiling should be used to avoid high volumes of data. Since WAS servers are Java-based, the -j on option to collect is always needed.

    Experiment Naming and Storage
    You can simplify the management of experiments by being careful at naming and storing them. You may name experiments with a -o argument specifying a name including the name of the server, followed by ".1.er". The first experiment will have the number 1, and subsequent ones will get consecutive numbers.
    You can also use the -d argument to specify a directory into which the experiments should be stored. It should be a locally-mounted, as opposed to NFS-mounted, file system.
    You may want to use the date command to generate a string representing the current date and time and embed that string in the experiment name.

    Signal Controls
    You may use the -y <signal> option to collect to control when data is recorded during the session, and minimize the volume of collected data.
    You may start the experiment with data collection paused (thus not profiling the server during its startup), and send the signal to resume data collection either just before or shortly after applying a benchmark load to the server.
    You would send the same signal to pause data collection either shortly before or just after the benchmark load is terminated.
    You may repeat the resume/pause sequence for other loads, and terminate the server after all are done.

    To profile server initialization, you would use -y <signal>,r, send the signal after initialization, and then send it again before and after a load is applied, as above.
    If data volume is not a problem, but you will be running multiple loads in a single session, you may pass the -l <signal> option to collect, and send the signal to insert sample markers after initialization and then after each benchmark load is applied.
    When using either of these techniques, you should disable periodic sampling, using the -S off option to collect.
    WebSphere does not interfere SIGPROF, so you can use it to generate samples or to toggle pause/resume, or to generate samples, but not both. Such use does not interfere with SIGPROF usage for clock-profiling. You can use a second signal, SIGUSR1, for example, if you want to both control pause and resume and to insert
    sample markers in the experiment.
    Descendant Process Controls
    Usually WAS Servers do not spawn additional processes, so -F on is not needed. If the server you are profiling does create additional processes
    that you wish to profile, you should enable -F to profile them, either for all descendants, or selectively, based on the name or lineage of the descendant of
    Archiving Controls
    Depending on the environment under which you are profiling WAS Servers, you may examine the data on the machine on which it was recorded.
    If you want to examine it on a different machine, you should set -A copy to make the experiment more portable.

    Initiating Data Collection

    This section describes how you can modify the scripts used to launch WAS servers to enable data collection.

    Launching the Servers with Collector/Analyzer
    WAS servers are simply launched by explicitly invoking the following script from the bin directory of the profile under which this server has been created.
    startServer.sh  <server name>
    eg. startServer.sh server1
    where "server1" is the name of the server.

    To start WAS with Sun Studio Collector/Analyzer tool we need to start server with "collect -j on" option so that data collection can be enabled.

    To do so follow the following steps:

    1. Go to the $PROFILE_DIR/bin dir.
    2. Issues the command:  startServer.sh <server_name> -script <script_name_to_be_used_with_collector>
    3. This will create a script name <script_name_to_be_used_with_collector>
    4. Now the script need to be modified to point to Sun Studio Collector/Analyzer tool binary location and start the java process with "collect -j on"
    5. Edit the script to have the Sun Studio bin dir in the PATH settings
      1. PATH=$PATH:/java/devtools/sparc/SUNWspro/SS11/bin
      2. You can put it either before or after . $binDir/setupCmdLine.sh line.
    6. Then replace "exec" in the script with "collect -j on". Save and quit the editor.
      1. exec "/opt/IBM-startup/WebSphere/AppServer/java/bin/java"
        will become collect -j on
      2. This is really a long line.
      3. You may not find exec if you are using 6.0.X based WAS
        installation then in that case you can just append "collect -j on " to
        the last line where the java commnad is launcehd.

    7. The server is now ready to be run with collector.

    The data will be collected in the directory from where you will invoke the <script_name_to_be_used_with_collector>
    script. You can invoke this script from anywhere as it doesn't have any relative path info.

    To force it to collect data in particular directory you mya want to use "-d" option in the script:

    -d <directory>        specify experiment directory

    An example of such a complex script can be found in the file start-collect.sh

    More information about the collect and analyze can be found in collect.1 man page.

    Server Profiles
    This section describes tips for examining the server profiles.
    Unless your server has created additional descendant processes which are profiled, and single run creates a single experiment. No experiment filtering of selectivity is needed.
    If you have used either of the signal mechanisms described above you may use sample filtering in the Analyzer or er_print to examine the profile for only part of the run. For example, you may want to look at the startup only, or you may want to look at the data for the individual benchmark loads that were run.

    When looking at the Timeline in Analyzer, you may want to color methods from the WAS infrastructure all one color, and use other coloring to look at specific sections of you code. You can also show or hide clock profile events that are not CPU-time (that is, they are system CPU-time, or any of the wait states).
    This is live document and we will keep on updating this more current updates.

    WAS Documentation
    Documentation for WAS 6.1 can be found on IBM's web site.
    Some topics of interest are:

    Thursday Oct 26, 2006

    WebSphere V6.0.2 and JVM 1.4.2 tuning on Solaris 10

    I have been asked this information many time so here is how you should tune the JVM for WebSphere Application Server on Solaris 10.

    The tuning knobs of interest:

    • initialHeapSize= eg. 2048
    • maximumHeapSize= eg. 2048
    • -server
    • -Xnoclassgc May not be needed for every other app
    • -Xmn1024m At least 50% of the heap size; more may be better
    • -XX:-UseAdaptiveSizePolicy
    • -XX:MaxTenuringThreshold=4
    • -XX:+UseParallelGC
    • -XX:ParallelGCThreads= either equal to number of cpu or on multi core systems set it to somewhere between .5-1xNumber of cores.
    • -XX:+AggressiveHeap

    Couple of things to note here when doing experimental work:
    You can try scaling up MaxTenuringThreshold to find out really at what time the object need to be promoted. Then similar things can be tried for Xmn or new generation size if you know for sure that you are going to generate lot of short lived objects then set it to higher percentage of Maximum Heap size.
    The other usual WebSphere App Server tuning would include following params:
    ORB Thread Pool
    WebContaine Thread Pool
    JDBC Connections
    EJB Cache
    HTTP Transport






    More about java performance check out:

    Tuesday Oct 24, 2006

    JSP pages compilation failure with WebSphere Application Server with java.lang.NoClassDefFoundError

    I happen to run into java.lang.NoClassDefFoundError when trying to run one of the sample JSP pages(hitcount) on WebSphere Application Server V6.1. Here is the exception trace(first few lines only):
    [10/13/06 16:32:51:941 PDT] 00000026 WebApp E [Servlet

    As we know that V6.1 has Eclipse based JSP compiler which uses JDT(Java Development Tooling) and AST(Abstract Syntax Tree) Parser for parsing and generating the java code.

    This compiler depends on some of the user env settings and if not propogated well to the compiler during the compiler initialization it may fail to initilize properly. There are two workarounds to this problem:

    • The easiest one is to install as any non-root user and everything should work as expected.
    • The other route you can take is modify your web archive descriptor to have JDK compiler or you can use jikes as well.

    To modify the compiler used for you JSP compilation you can edit your ibm-web-ext.xmi file under the web module deployment directory and can have a line similar to this:

    <jspAttributes xmi:id="JSPAttribute_XXXXX" name="useJDKCompiler" value="true"/>

    For XXXXX you can put any number all you have to do is just make sure JSPAttribute_XXXXX is unique. There are bunch of other as well which can be changed for you web-application.
    IBM web-site looks like the fix for this is also going to be released very soon...

    Tuesday Sep 26, 2006

    Does memory usage really increase when upgrading to WebSphere Application Server V6.1 on Solaris ?

    In reference to IBM Flash(Alert) that has been posted by IBM does not provide the
    technical details and does not discuss about why one would observe this
    growth in memory if not used in way they have been using it with J2SE
    1.4.   In nutshell, this is not a growth in memory.  It
    is just the technology changes from J2SE 1.4.2 to 1.5.  In J2SE
    5.0, we all know that a lot of things has been

    Some of the defaults(configuration) that were used with J2SE 1.4.2
    before has been changed in 1.5.  As a result, the Java Virtual
    Machine (JVM) if started on the same hardware or server will have
    different settings with 1.5 JVM which is tuned mostly for the server
    class application as opposed to 1.4.2 which is tuned for client class
    uses.  When you start your JVM without supplying any JVM options
    (defaults) with 1.4.2 and 1.5, you will find lot of difference in the
    JVM settings in the two JVM's. We need to understand a bit about this
    as to why this is changed.  To understand it well, we have to look
    at the changes in J2SE 1.5 that has introduced following new feature
    which is relevant in this case:

    I am sure if you are interesetd you will follow the link and get the
    details but here is a summary whats happening in here. When 1.5 JVM is
    started on a particular classe of machine, it adjusts the JVM
    parameters based on resources on the machine e.g. memory and cpu. It is
    not just the heap size settings (e.g. Xms and Xmx), there are other
    options as well which will have different settings. If your machine is
    deteced to be the server class machine, it is going to start the server
    JVM otherwise it will start the client  JVM. While in J2SE 1.4.2,
    client JVM has always been the case unless you specify the "-server"
    excplicitly in your settings. Then, the Garbage Collector is also
    different on the class of machine you have.

    The IBM Flash tuning reccomendation is just to override the Garbage
    Collector Ergornomics and Server-Class machine detection feature of the
    J2SE 1.5 and bring it to the same options level as 1.4.2 JVM. It makes
    sense here as now we will be comparing the two JVM at the same level
    and you will find that the 1.5 JVM will have the lesser footprint. You
    may find people using the term like de-tuning for this but actually you
    may by this time will understand that this is actually not de-tuning
    but bringing the JVM 1.5 to 1.4.2 level and doing an apple to apple
    comparision. Not many production system that drive really heavy
    workloads will use in these type of constrained environment and will
    favour the ergonomics feature of the 1.5 JVM.

    If you are interested in more details about the Sun JVM tuning, there
    are plenty of resources to help you such as Java SE Performance is great place to start.

    Thursday Aug 17, 2006

    WebSphere SpecJAppServer2004 benchmark on Sun Fire T2000

    Sun Fire T2000 so far has been the best J2EE app server platform [Read More]

    Wednesday Aug 16, 2006

    WebSphere Application Server V6.X in Solaris 10 Zone container

    Virtualization techniques for WebSphere [Read More]

    Monday Aug 14, 2006

    WebSphere Application Server V6.1 on Sun Fire T2000

    How to tune WebSphere on Niagara servers[Read More]



    « July 2016