EditAttachPrintable
r1 - 2013-09-18 - 13:27:09 - StevenBeardYou are here: TWiki >  Deployment Web > TuningWAS > WASTopTuningRecommendations

uc.png General WebSphere Application Server top tuning recommendations

Authors: Surya V Duggirala, IBM WebSphere Chief Performance Architect
Build basis: None

Note: This topic page is based on a talk given at IMPACT 2011 by WebSphere Chief Performance Architect Surya Duggirala and updated to reflect current best practice.

This topic page will cover general WebSphere Application Server (WAS) tuning guidance. Please look at Tuning WebSphere Application Server for Rational Jazz specific guidance and best practice.

Properly tune the operating system

  • Operating System (OS) is consistently overlooked for functional tuning as well as performance tuning.
  • Understand the hardware infrastructure backing your OS. Processor counts, speed, shared/unshared, etc.
  • ulimit values need to be set correctly. Main player here is the number of open file handles (ulimit –n). Other process size and memory ones may need to be set based on application.
  • Make sure NICs are set to full duplex and correct speeds.
  • Large pages need to be enabled to take advantage of –Xlp JDK parametes.
  • If enabled by default check RAS settings on OS and tune them down.
  • Configure TCP/IP timeouts correctly for your applications needs.
  • Depending on the load being placed on the system look into advanced tuning techniques such as pinning WAS processes via RSET or TASKSET as well as pinning IRQ interrupts.

Keep application logging to a minimum

  • Never should there be information outside of error cases being written to SystemOut.log.
  • If using logging build your log messages only when needed.
  • Good
    • if(loggingEnabled==true){ errorMsg = “This is a bad error” + “ “ + failingObject.printError();}
  • Bad
    • errorMsg = “This is a bad error” + “ “ + failingObject.printError();
      If(loggingEnabled==true){ System.out.println(errorMsg); }
  • Keep error and log messages to the point and easy to debug
  • If using Apache Commons, Log4J, or other frameworks ensure performance on your system is as expected.
  • Ensure if you must log information for audit purposes or other reasons that you are writing to a fast disk.

Understand and tune infrastructure (databases & other interactive server systems)

  • WAS and the system it runs on is typically only one part of the datacenter infrastructure and it has a good deal of reliance on other areas performing properly.Think of your infrastructure as a plumbing system. Optimal drain performance only occurs when no pipes are clogged.
  • On the WAS system itself you need to be vary aware of:
    • What other WAS instances (JVMs) are doing and their CPU / IO profiles.
    • How much memory other WAS instance (or other OS’s in a virtualized case) are using.
    • Network utilization of other applications coexisting on the same hardware.
  • In the supporting infrastructure:
    • Varying Network Latency can drastically effect split cell topologies, cross site data replication and database query latency.
      • Ensure network infrastructure is repeatable and robust.
      • Don’t take for granted bandwidth or latency before going into production always test as labs vary.
    • Firewalls can cause issues with data transfer latencies between systems.
  • On the database system:
    • Ensure that proper indexes and tuning is done for the applications request patterns.
    • Ensure that the database supports the number of connected clients your WAS runtime will have.
    • Understand the CPU load and impacts of other applications (batch, OLTP, etc all competing with your applications).
  • On other application server systems or interactive server systems:
    • Ensure performance of connected applications is up for the load being requested of it by the WAS system.
    • Verify that developers have coded specific handling mechanisms for when connected applications go down (You need to avoid storm drain scenarios).

Minimize HTTP session content

  • High performance data replication for application availability depends on correctly sized session data.
    • Keep it under 1MB in all cases if possible.
  • Only should be storing information critical to that users specific interaction with the server.
  • If composite data is required build it progressively as the interaction occurs.
    • Configure Session Replication in WAS to meet your needs.
    • Use different configuration options (async vs. synch) to give you the availability your application needs without compromising response time.
    • Select the replication topology that works best for you (DB, M2M, M2M Server).
    • Keep replication domains small and/or partition where possible.

Related topics: Tuning WebSphere Application Server

External links:

Additional contributors: StevenBeard

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r6 | r4 < r3 < r2 < r1 | More topic actions...
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Ideas, requests, problems regarding the Deployment wiki? Create a new task in the RTC Deployment wiki project