Download WebSphere Commerce Top DB2 Performance Problems

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Oracle Database wikipedia , lookup

Microsoft SQL Server wikipedia , lookup

Extensible Storage Engine wikipedia , lookup

Database wikipedia , lookup

Relational model wikipedia , lookup

Encyclopedia of World Problems and Human Potential wikipedia , lookup

Microsoft Jet Database Engine wikipedia , lookup

Concurrency control wikipedia , lookup

Database model wikipedia , lookup

Clusterpoint wikipedia , lookup

ContactPoint wikipedia , lookup

Transcript
Performance: WebSphere Commerce
John Tullis
DePaul Instructor
[email protected]
Copyrighted material
John Tullis
5/22/2017
page 1
Performance: WebSphere Commerce
Problems with solution components
• Webservers
• WebSphere Commerce engine
• Database server.
Copyrighted material
John Tullis
5/22/2017
page 2
Performance: WebSphere Commerce
Top Webserver Performance Problems
• Static page caching not fully utilized
• Cache as many HTML and graphics files as your webserver
memory will allow.
• Unnecessary PASS directives not removed from configuration
files.
• Cleaning up PASS directives will minimize the execution
path of the webserver for each request it sees
• Value of MaxActiveThreads too low
• Increasing the value will allow higher throughput
Copyrighted material
John Tullis
5/22/2017
page 3
Performance: WebSphere Commerce
Top Webserver Performance Problems
• Unnecessary access logging information being collected
• Collect only the webserver log information you plan to
use
• High request graphics not cached
• Cache all high request graphics files
• Webserver access logs processed on-line
• All access log processing should be handled off-line,
on a separate machine
Copyrighted material
John Tullis
5/22/2017
page 4
Performance: WebSphere Commerce
Top Websphere Commerce Performance Problems
• Too many/few server processes running
• If CPU and/or memory resources on the
Net.Commerce server are consistently running above
80% utilization then the number of server processes
can be reduced and additional servers may be required
• If there is excess CPU and memory capacity (less
than, say 30% utilization) then the number of server
processes can be increased
Copyrighted material
John Tullis
5/22/2017
page 5
Performance: WebSphere Commerce
Top Websphere Commerce Performance Problems
• Too many directories in the Net.Data macro and HTML
path
• Reduce the number of directories and the search time
to locate macro and include files will be reduced
• Dynamic HTML page caching not enabled
• Dynamic page caching provides large performance
gains and should always be activated
• With dynamic page caching Net.Commerce can serve
a previously created and cached product or category
page from disk rather than having to build the page
from scratch by running a Net.Data macro against the
database
Copyrighted material
John Tullis
5/22/2017
page 6
Performance: WebSphere Commerce
Top Websphere Commerce Performance Problems
• Not fully utilizing the dynamic caching capabilities
• Generating product and category pages via
ExecMacro calls rather than using the ProductDisplay
and CategoryDisplay commands does not generate
cacheable pages
• Insufficient indexes for queries being executed in
Net.Data macros
• Create indexes for queries as necessary based on
results of query optimization as described above
Copyrighted material
John Tullis
5/22/2017
page 7
Performance: WebSphere Commerce
Top DB2 Performance Problems
• Insufficient number of physical disks available to balance I/O
• There must be adequate disks available for the database
and database logs to guard against bottleneck problems
• 4 - 6 drives per CPU for the database and 2 dedicated disks
for the logs is a good starting point
Copyrighted material
John Tullis
5/22/2017
page 8
Performance: WebSphere Commerce
Top DB2 Performance Problems
• Inadequate bufferpool size
• On a database server which is running only DB2 with a single
Websphere Commerce database on a single instance, 75% of the
physical memory on the machine can be allocated for bufferpool
• Use only one large bufferpool
• If using one bufferpool, size it to the minimum of total database
size or maximum amount of shared memory
• If using multiple bufferpools, ensure they are sized according to
the tablespaces using them (i.e. allocate the bufferpool to be the
same size as the tablespace). You can leave extra space for growth
if the database is small, and if you are close to the bufferpool
limits (see next bullet) make the bufferpool the same size as the
tablespace
Copyrighted material
John Tullis
5/22/2017
page 9
Performance: WebSphere Commerce
Top DB2 Performance Problems
• Note the following limitations/notes on bufferpool size for Unix
platforms
 UNIX limits are on total shared segments: These include: Utility
heap 20MB, dbheap 20MB each, locklist 16MB pckcache 26MB,
sortheapthresh, etc. The database and database manager
configuration will have to be inspected to determine these
 The size of the shared memory segment size (shmmax) parameter
may need to be increased if it is too low. This could be set to
approx 3 to 3.5Gig just to remove any limitations on it
Copyrighted material
John Tullis
5/22/2017
page 10
Performance: WebSphere Commerce
Top DB2 Performance Problems
• Database logs should be located on their own physical disks
• Since the database is constantly writing to it’s logs, they should
reside on separate physical disks than the database to reduce I/O
contention
• Unused space in database tables not reclaimed
• When a row in a table is deleted the space occupied by the row is
not necessarily reclaimed until the table is reorganized
• Key database tables should be reorganized regularly to keep the
database at a minimum size to ensure optimal access plans
Copyrighted material
John Tullis
5/22/2017
page 11
Performance: WebSphere Commerce
Top Performance & Load Testing Problems
• Performance goals for the site not clearly stated
• Clear performance goals for the site were never defined or
defined in such a way that measurement is impossible
• Lack of performance testing
• No performance testing methodology defined
• Lack of definition of testing tools used, in which environments
and at what load targets
• Inadequate load testing performed
• Lack of realistic load testing target
• Site should be stressed to the breaking point
• Inadequate functional testing performed
• All key site functions, for both shoppers and administrators,
should be thoroughly tested
Copyrighted material
John Tullis
5/22/2017
page 12