RE: Need better WebSphere Application Server Performance for

Dave,

Our WebSphere App Server usage is because we run JDPeopOracle
EnterpriseOne, The Product Formerly Known As OneWorld.  Our installation
was Oracle-certified (i.e. performed by Oracle) but that did not include
any real performance tuning.  Thus it did not address memory pool
settings and whatnot.

I also recall we tweaked the heap size for the JVM.   And we have
created a few indexes since then to tweak performance, although not so
much WAS-related.  Just a data point that an install that's "by the
books" doesn't necessarily result in anything close to an
optimal/tuned-for-performance setup.

We never compared performance of EnterpriseOne (E1) on WAS on i5 v. WAS
on Windows v. E1 Fat Client.  Fat Client was out as the app is deployed
globally (45 countries and counting) and the bandwidth requirements
would simply not work.  Users in Poland, for instance, don't have access
better than dialup.  WAS on Windows is an option but our app technical
specialist and I agree that we didn't want the added complexity of a
multi-platform setup.  Also, when running on a single hardware platform
you can share resources; when CPU isn't needed for WAS it can be used
for batch or other tasks.  Plus, over the useful life of the environment
our cost structure favors the iSeries over Windows.

You'll probably find QZDASOINIT jobs consuming resources when
performance is poor.  Those are the server jobs that in most cases
handle ODBC/JDBC/etc.  There articles online (use Google) and some stuff
in the list archives about tweaking QZDASOINIT jobs for performance.
Don't expect radical gains.

Oh, as to assigning CPU & memory resources, i5/OS runs rings around
Windows.  On Windows you can set processor affinity and choose from a
handful of priorities but that's about it from a CPU standpoint.  For
RAM, Windows doesn't let you control anything beyond page file
size/location.  You can't dedicate __MB RAM to a single process, at
least not that I'm aware.  Windows has no concept of subsystem.

We've also run into issues with E1's business unit security.  If a
user's business unit security is too complicated (lots of non-adjacent
groups of BUs), their access really slows down.  E1 sends what is
essentially non-optimized SQL to the database server (i5).

There are also some architectural issues in E1.  We've caught some
business logic running in WAS v. in the app server piece where it
belongs.  Those bits naturally are very slow compared to native code and
might be way faster on the fat client.

Solution: Throw hardware at it.  In a couple of months we'll be
upgrading the hardware from a 2-way i5 (POWER5) to a 4/8-way i5
(POWER5+) (from 6000 to 16100 CPWs) and will double RAM to 64GB.  Not
cheap but we have a lot more users to add in 2007.

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave Odom
Sent: Wednesday, November 15, 2006 12:08 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Need better WebSphere Application Server Performance for

Walden, John, Shalom, et al,
 
Thanks to all for your assistance and keep the suggestions coming... 
To answer your questions:
 
Yes, all three "O" products are using the same i5 DB2 database and table
(singular at this point), a simple SELECT of all columns so
nothing remotely fancy.   
 
As to a missing index... first, how come the Windows version of the "O"
product screams and the WebSphere version/installations don't.   Second,
until and unless I can get the place to go for putting copies of all
tables frequently queried in an Operational Data Store or Data Mart or
Data Warehouse where they can be tuned with indexes that support common
queries,  I'm stuck with the table and index design of the vendor that
created the packaged applications used most by the business.  
 
I'll look again for any "O" vendor recommended setups for memory,
processor, memory pools, JVM settings, etc.  From what I know, the
systems programmers that installed WebSphere in all instances and the
"O" product installations went by the books of both products.  I'll
recheck.
 
Shalom... you asked "Do the was installations work with a server JDBC
resource?"   I don't understand your question.  What's a server JDBC
resource?   The WAS installs were done according to the documentation on
the WAS product as far as I know.   Now it may be that some pieces of
the WAS install can be segregated so they get better memory and
processor power and that may be easier for a WAS Windoz install but I'd
really like to improve the WAS i5 install because I'd like to stay off
Windoz as much as possible.
 
John Jones... Your recommendations were most detailed and oriented to an
i5.  Super!!  I'll investigate.  
 
Thanks again,
 
Dave Odom
Arizona
 
 
 
 
 
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.



This email is for the use of the intended recipient(s) only.  If you have 
received this email in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this email without the author's prior permission.  
We have taken precautions to minimize the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any attachment 
to this message.  We cannot accept liability for any loss or damage caused by 
software viruses.  The information contained in this communication may be 
confidential and may be subject to the attorney-client privilege. If you are 
the intended recipient and you do not wish to receive similar electronic 
messages from us in the future then please respond to the sender to this effect.