Many Customer are asking what is changed by using this tool. I have
performed some research on the tool and based on the Tool update
from 03/19/14 here is what I have found related to the
configuration changes that are performed by the tool

The Bulk of the tuning changes that will be performed for the JVM
and web container service are found in the TuningTask directory in
the archive in the file named tuning.properties. The first 5 lines
are what the user sets for the environment they are configuring as
follows
# - this is set to true if wcm rendering is being used on the site
tuning.wcm=true
# - set the following to true for a subscriber only :ie this does
not syndicate content to other environments
tuning.wcm.subscriberOnly=true environments
#- this is set to false of running the command against a rendering
environment and true if it is an authoring environment
tuning.wcm.authoring=false - only set this to true for authoring
environments

# managed pages is a Portal V8+ feature that allows WCM to manage
page #definitions. If you want the "edit" button on the V8 theme,
you have to set #managedPages to "true"
tuning.wcm.managedPages.inlineEdit=true
#set the bit level of the jvm environment being configured
tuning.os.bit=64

#The other properties in this file sets the JVM Heap initial amd
Max size as well as
# other generic jvm arguments depending on the OS being used per
the tuning
# guide recommendations the values here are the values that will be
configured in
# the Process definition for the Server being configured

# The properties from here to the end of file are recommendations
from IBM on the
#initial tuning recommendations
tuning.64.linux.maxHeap=3584
tuning.64.zlinux.maxHeap=3584
tuning.64.zos.maxHeap=3584
tuning.64.windows.maxHeap=3584
tuning.64.aix.maxHeap=3584
tuning.64.unix.maxHeap=3584
tuning.64.os400.maxHeap=3584

tuning.32.linux.maxHeap=2048
tuning.32.windows.maxHeap=1408
tuning.32.aix.maxHeap=1792
## The next three OSes are not known to be used in 32 bit mode but
are included
# here for completeness
tuning.32.unix.maxHeap=1792
tuning.32.zlinux.maxHeap=1792
tuning.32.zos.maxHeap=1792
tuning.32.os400.maxHeap=1792

## All these settings would be in the Generic JVM ArgumentsM
# sets -XX:MaxDirectMemorySize=256000000
tuning.all.DirectMemorySize=256000000
# sets --Xjit:iprofilerMemoryConsumptionLimit=67108864
tuning.all.MemoryConsumptionLimit=67108864
# sets -Dcom.ibm.websphere.alarmthreadmonitor.threshold.millis=
tuning.all.AlarmMonitor=40000
# sets -Xscmx150m note it must also be destroyed for this to take
effect
tuning.all.SharedClassCache=150m
# sets -Xcodecache20m if running on power 7 hardware
tuning.power7.CodeCache=20m

## Avoid Refreshing Static Content which allows the modular theme
to avoid
#reloads on login.
## These resources include the ra: collection URLs that are part of
the theme. The
#same URL can safely be used for authenticated and unauthenticated
users.
## The default is "lazy". "Persisting" provides better performance.
"Persisting"
#means the checkbox "Use available authentication data when an
unprotected
#URI is accessed" was checked.
# WebSphere Integrated Solutions Console: Security > Global
security
#2. Expand Web and SIP security
#3. Click on General Settings
#4. Check 'Use available authentication data when an unprotected
URI is
#accessed'
tuning.all.security.avoidRefreshStaticContent=persisting

########
# This cache uses more memory per object than other caches.
# The value should be set based on the number of concurrent, logged
in users. Larger values may require a larger JVM heap size.
# A value of 6,000 was used to support 6,000 virtual users in the
benchmark measurements.
# Increasing to 7,000 in other measurements increased throughput
but required a heap size of 4,608 MB.#
#########

I was talking some recent SWAT activity with our local Sametime Guru - Casey Toole. We had a couple really painful issues that came up recently. Issues like a server going down, long service outages and tons of scrambling to get things back in order. Well once the dust settled, these problems all came back to being able to conduct high quality reads and writes to the filesystem.

What makes this an especially painful process is that in most shops, the application administrator (Domino, Sametime, Connections etc.) doesn't have the power to address disk subsystem issues. And the last thing you want to do is be stuck in a situation where people are screaming about service and you are having to prove the problem is with someone else. Let's say responsibility is never readily accepted 9 times out of 10,

So before you do anything, make sure that your disk subsystem is healthy . Check your response times and your error logs regularly. And don't forget a daily dose maintenance.