Stat Logging Levels and Their Effect? Affect? Impact!

Stat Logging Levels can have a major affect on migration performance…  {Hmm… Doesn’t look right.}
Stat Logging Levels can have a major effect on migration performance...  {Nope… Sounds wrong.}
Stat Logging Levels can have a major impact on migration performance…  {Lazy… I’ll change it later…}

Affect? Effect? Ugh…  I’m pretty sure I missed class when they discussed Effect/Affect; I always goof the two up!  I really should know this...
After all I work in IT…  I’m supposed to be intelligent... 
If I get this wrong in an email, or a post, it could have a negative effect on me.   It could affect my ability to get a promotion someday. 

Many times during implementation the Stat Central Agent (SCA) Logging level gets set to ‘DEBUG’ to either debug a specific issue or to ensure all is working as expected.  However, as happens in many areas of one’s life, we forget to go back and adjust the things we intended to adjust.   

Check SCA Log Settings:
There are two ways to check the current logging level of your system.  They are through the Stat Windows client or the Stat Web client. 

Stat Windows Client:
Within the Stat Windows Client: From the main console go to the tool bar and select: Tools > Stat Central Agent Status.  You should see the following:

Stat Web Client:
To access the Stat Configuration through the Stat Web Client point your browser to the stat-config page. 
Open your browser and go to http://<stat_server_host>:8080/stat-config.

* If you receive an error accessing the configuration page – you need to set authorization to access it.  See the Stat Install Guide section “Authorize access to the Configuration page” to allow access.

Options: 
There are seven levels of logging that can be set in the SCA. 
They are as follows:  From low to high is: OFF, FATAL, ERROR, WARN, INFO, DEBUG, ALL

According to the install guide, the default setting is INFO.  (See pg. 18 of the Stat install guide.)

How to Affect Change to Make an Effect on Performance:
The setting chosen can have a bigger impact on the system than you may think.  The following screenshot shows three separate migrations.

Test Data: 
The same objects/code sets were used in all four of the test migrations.  Only the logging levels were changed between each of the test migrations.  
The archive set was migrated several times prior to starting the test to ensure successful migration and to cache any settings needed that could possibly throw off any initial results.

The Results:
The following table shows the differences in migration time:

As you can see from the above table or the below screenshot, the difference between no logging and all logging is significant.   
Even though the data set was small, the difference between no logging and all logging is almost double the migration time.

Had this code set been a large project or patch set the impact would have been more significant.   The choice to be made is what value is enough to ensure you capture any critical errors and what’s the cost of that choice.  

The logging value can be changed while the SCA is running but it will not take effect until the SCA is restarted.  

Darn… this blog is now posted and I never did go back and change the introduction line with the proper affect/effect usage. 

Thank you for taking the time to read this post!  Be Happy – Be Statisfied*.

Respectfully,

William R. Hart
Solutions Architect 
Quest | Presales

Additional Tips: 
* You will need to restart the Stat Central Agent each time the logging settings are changed. 
* The values discussed are specific to the Stat Central Agent (SCA) and should not be confused with the Stat Oracle Agent (Stat for Oracle eBusiness).
* Kudos to Tim on coining the word “Statisfied”.

Now back to our lesson: Affect vs. Effect. I just love this one!

About the Author
William.Hart
Promoting a positive Stat User Community and enriching the value of the Stat investment. William has worked with the Stat application for over twelve years. He specializes in the areas of PeopleSoft and...