[cvs] Expresso commit by mtraum: deleted - split into 2 other
chapters a
JCorporate Ltd
jcorp at jcorp2.servlets.net
Mon Oct 4 19:53:27 PDT 2004
Log Message:
-----------
deleted - split into 2 other chapters a while ago
Removed Files:
-------------
expresso/expresso-web/expresso/doc/edg:
edg_operation.html
Revision Data
-------------
--- expresso-web/expresso/doc/edg/edg_operation.html
+++ /dev/null
@@ -1,684 +0,0 @@
-<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 20. Monitoring and Verifying the Operation of Expresso Applications</title><link href="docbook.css" rel="stylesheet" type="text/css"><meta content="DocBook XSL Stylesheets V1.62.4" name="generator"><link rel="home" href="edg_index.html" title="Expresso Developer's Guide"><link rel="up" href="edg_index.html" title="Expresso Developer's Guide"><link rel="previous" href="edg_deploy.html" title="Chapter 19. Expresso Component Application Deployment"><link rel="next" href="edg_jobcontrol.html" title="Chapter 21. Jobs Expresso"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter 20. Monitoring and Verifying the Operation of Expresso Applications</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="edg_deploy.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="edg_jobcontrol.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="operation"></a>Chapter 20. Monitoring and Verifying the Operation of Expresso Applications</h2></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="edg_operation.html#N12299">Unit Tests</a></span></dt><dt><span class="sect1"><a href="edg_operation.html#clienttest">Client-side Tests</a></span></dt><dd><dl><dt><span class="sect2"><a href="edg_operation.html#N122D9">Client Side Testing</a></span></dt><dt><span class="sect2"><a href="edg_operation.html#N122E5"></a></span></dt><dt><span class="sect2"><a href="edg_operation.html#N122ED">Writing your test case guidelines</a></span></dt><dt><span class="sect2"><a href="edg_operation.html#N12301">Schema Testing</a></span></dt><dt!
><span class="sect2"><a href="edg_operation.html#N1230E">Server Side Testing</a></span></dt><dt><span class="sect2"><a href="edg_operation.html#N1231F">A Quick Sample</a></span></dt><dt><span class="sect2"><a href="edg_operation.html#N1234D">Running The Test Case</a></span></dt></dl></dd><dt><span class="sect1"><a href="edg_operation.html#N1237A">Performance Tests</a></span></dt><dd><dl><dt><span class="sect2"><a href="edg_operation.html#N1238D">Using Performance Tests</a></span></dt></dl></dd><dt><span class="sect1"><a href="edg_operation.html#N123BA">Optimizing Performance</a></span></dt><dd><dl><dt><span class="sect2"><a href="edg_operation.html#N123BF">Performance Hogs</a></span></dt><dt><span class="sect2"><a href="edg_operation.html#N123F8">Cache Tuning</a></span></dt></dl></dd><dt><span class="sect1"><a href="edg_operation.html#N12420">Database Optimization</a></span></dt><dt><span class="sect1"><a href="edg_operation.html#N12427">Indexing</a></span></dt><dt><span class="sect1"><a href="edg_operation.html#N1242D">Conclusion</a></span></dt><dd><dl><dt><span class="sect2"><a href="edg_operation.html#N12430">Contributors</a></span></dt></dl></dd></dl></div><p>
-
- <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
-If you find this EDG documentation helpful please consider <a href="edg_operation.html#donate_operation">DONATING</a>!
-to keep the doc alive and current.
- </p></div>
- </p><p>
-
- <div class="informaltable"><table width="100%" border="0"><colgroup><col align="left"><col align="right"></colgroup><tbody><tr><td align="left"><span class="bold"><b>Version:</b></span><span class="version">Expresso 5.5</span></td><td align="right"><span class="bold"><b>Maintainer:</b></span><a href="mailto:dlloyd at jgroup.net?Subject=EDG" target="_top"><span class="maintainer">David Lloyd</span></a></td></tr></tbody></table></div>
- </p><p>
-Now that you have your application developed and deployed, what tools are
-available for you to monitor and maintain your application? You want to
-ensure that the individual components of Expresso and your custom components
-are operating correctly, to ensure that your applications stays operational
-and available to users, and to ensure that it's performance is acceptable
-and does not degrade over time.
- </p><p>
-Tools exist within Expresso to verify it's own functioning and the function
-of any other web application. These tools consist of two types: Unit tests
-and Performance Tests.
- </p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N12299"></a>Unit Tests</h2></div></div><div></div></div><a name="N1229C" class="indexterm"></a><p>
-Expresso contains the <a href="http://junit.sourceforge.net/#Documentation" target="_top">JUnit
-framework</a> - a unit testing framework that allows the individual
-components of Expresso to be tested and verified as functioning correctly.
-Expresso applications can (and should) also include a number of unit tests.
-Unit tests differ from Performance Tests (covered below) in that they deal
-with individual components, making it easier to locate and correct a problem
-before components are assembled into a finished application.
- </p><p>
-It was necessary to extend JUnit because Expresso applications expect certain
-system configurations to be available at any given time. These include
-database configuration, as well, as web-application location (which would
-normally be gleaned off of the servlet container). Further extensions were
-needed to be able to run test cases within a servlet container.
- </p><p>
-To accomplish this, we branched into two areas:
- <div class="itemizedlist"><ul type="disc"><li><p>
-Client Side Testing involves any areas that can be run without a servlet
-container. There are a surprising large number of subsystems that just
-need the underlying Expresso database framework, and not the servlet containers.
-This also contains a special case of Schema Testing that is covered below
-too.
- </p></li><li><p>
-Server Side Testing involves testing of Servlets and Controllers.
- </p></li></ul></div>
- </p><p>
-You can use your IDE, like Eclipse or Idea or JBuilder, to run unit tests.
-Set up VM arguments as:
- </p><pre class="programlisting">-Djunit.argv.configDir=./WEB-INF/config
- -Djunit.argv.webAppDir=./
- -Djunit.argv.testContext=default
- -Djunit.argv.logDir=/home/tomcat/logs
- -Djunit.argv.loggingConfiguration=./WEB-INF/config/expressoLogging.xml</pre><p>
-Then choose a test suite to run. The do-everything test is: com.jcorporate.expresso.core.ExpressoTestSuite
-, which will run all JUnit tests.
- </p><p>
-Also, you can use the standard JUnit user interfaces for running unit tests
-such as the TextUI or SwingUI classes. For more information on JUnit, check
-out <a href="http://www.junit.org/" target="_top">JUnit's Web Site</a>
- </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="clienttest"></a>Client-side Tests</h2></div></div><div></div></div><a name="N122C7" class="indexterm"></a><p>
-Expresso web applications can be tested via free tools like <a href="http://httpunit.org" target="_top">httpunit</a>,
-which offer a brower-like client to test individual pages. Built on top
-of httpunit, <a href="http://morebot.org" target="_top">Morebot</a> has special
-support for Expresso, and can provide a cursory test the majority of your
-application by "spidering" (following links) it after logging in. Morebot
-can dispatch several of these tests simultaneously to serve as a load test
-for your server.
- </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N122D9"></a>Client Side Testing</h3></div></div><div></div></div><p>
-
-To provide a framework that we can perform client side testing with all
-standard expresso services such as logging, database connection management,
-and many others we provide the following class:
- <tt class="classname">com.jcorporate.expresso.services.test.ExpressoTestCase</tt>
-
-. To create your own test case use the following sample as a model:
- <pre class="programlisting">
-import junit.framework.*;
-import junit.extensions.*;
-import com.jcorporate.expresso.services.test.*;
-
-
-public class SampleTestSuite extends ExpressoTestCase {
- public SampleTestSuite(String name) throws Exception {
- super(name);
- }
-
-
- public static void main(String[] args) throws java.lang.Exception {
- //Set the system properties we need
- junit.textui.TestRunner.run (suite());
- }
-
-
- public static junit.framework.Test suite() {
- return new TestSuite(SampleTestSuite.class);
- }
-
- public void test1() {
- //Do your testing code here
- }
-
- public void test2() {
- //Do more testing here
- }
-
- public void test3() {
- //You can do more testing here
- }
- /*....Do as many test cases as you want, all with the public void signature */
-}</pre>
- </p></div><div class="sect2" lang="en"><div class="titlepage"><div></div><div></div></div><p>
-The JUnit framework will automatically use Java Introspection to run all
-the public(void) test cases. See the JUnit documentation on how to use
-the framework to signal if a test passed or failed. Also, see the class:
-com.jcorporate.expresso.core.misc.CookieTests to see a fully functional
-sample of integration with JUnit Framework.
- </p><p>
-
-All expresso test case classes will play well with the JUnit test runners.
-So if you wish to run a text-based only test case, you can run junit.textui.TextRunner.
-If you wish to run within a nice graphical environment, you can run your
-test suite with:
- <tt class="classname">junit.swingui.TestRunner</tt>
-
-. use the UI to pick the class you wish to test and let her run. The -c
-will determine which test suite to run. You can use your own test cases,
-or use the class sample above to run all Expresso test cases at once.
- </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N122ED"></a>Writing your test case guidelines</h3></div></div><div></div></div><p>
-
-There are a couple of necessary guidelines to follow when writing your
-own test cases:
- <div class="itemizedlist"><ul type="disc"><li><p>
-Make sure that your tests are fully automated. This will indeed pretty
-much take the most work in creating your test cases, but without that automation,
-it is <span class="bold"><b>IMPOSSIBLE</b></span> to spot any minor errors
-that creep into your code while refactoring. It cannot be stressed how
-much your time will be saved in the long run if you can think of ways to
-automatically check for proper behavior.
- </p></li><li><p>
-Whenever you need the expresso environment properly running, make sure
-you derive from ExpressoTestCase.
- </p></li><li><p>
-Always include a main() function. This allows for extremely quick testing
-while you're building your classes and tests.
- </p></li></ul></div>
- </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N12301"></a>Schema Testing</h3></div></div><div></div></div><p>
-
-When we're first creating our application, we want to make sure it runs
-correctly, right? But as we're developing our schema, and creating out
-databases, we have to each time go through the monotonous task of dropping
-a database, recreating it, starting up Expresso, running DBCreate, etc.
-This quickly becomes quite a chore. So we've created a special test case
-for testing Schema Creation. Here's all the code you need. The following
-example is borrowed directly from eForum and is complete:
- <pre class="programlisting">
-import junit.framework.*;
-Import com.jcorporate.expresso.services.test.*;
-Import com.jcorporate.expresso.core.utility.DBToolTests;
-
-public class SchemaTests extends DBToolTests {
- public SchemaTests(String testName) throws Exception {
- super(testName);
- }
-
- public static void main(String[] args) throws Exception {
- //Set the system properties we need
- junit.textui.TestRunner.run (suite());
- }
-
- public static junit.framework.Test suite() throws Exception {
- return DBToolTests.suite();
- }
-
- protected void setUp() throws Exception {
- //System must be initialized prior to instanatiating the schema instance
- TestSystemInitializer.setUp();
- Class c = Class.forName("com.jcorporate.eforum.ForumSchema");
- schemaList.add(c.newInstance());
- super.setUp();
- }
-}
-</pre>
- </p><p>
-That's it! To make this code work for your schema all you do is change
-the ONE line in setup() that loads ForumSchema to use your own schema class.
-When this class is run, it will make sure that all tables are removed from
-the Test database, and then attempt to create all schemas (Including Expresso's)
-in the test database. It will also run separately populateDefaultValues()
-and setupDefaultSecurity() so you can make sure that everything is cooprating.
- </p><p>
-This kind of testing is an extremely helpful and powerful tool for testing
-your schemas as you're building them.
- </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1230E"></a>Server Side Testing</h3></div></div><div></div></div><p>
-The bulk of your web application is going to be logic within an Expresso
-Controller object, or possibly a standard Servlet. Unfortunately, standard
-JUnit client-side testing procedures definitely fall flat in being able
-to cope in this area. Enter Apache's Cactus project.
- </p><p>
-Cactus was designed to provide the unification of JUnit's client side testing
-API and in-container server-side testing. What it does is initiate a test
-case on the client side so you can stuff all the HTTP request parameters
-with everything you need such as state to request, login cookies, etc.
-The test case then serializes itself to the server, where a specially designed
-servlet loads your test class and executes the code on the server side.
-The result is then sent back to the client side so you can examine cookies
-sent back to client or other results.
- </p><p>
-If you are writing a servlet, the Cactus documentation will be sufficient
-to get you started on a servlet. Even if you're writing a controller test
-case, it is strongly recommended that you browse through the Cactus website
-to get an idea of how a Cactus test case is written since the controller
-test cases are extensions to a standard Cactus test.
- </p><p>
-
-If you are writing a controller test harness, there are quite a few things
-to consider such as having a running underlying database, negotiating security,
-and parsing the controller response. To assist in this, we've provided
-the classes:
- <tt class="classname">com.jcorporporate.expresso.services.test.ControllerTestCase</tt>
-and
- <tt class="classname">com.jcorporate.expresso.services.test.ControllerTestSuite</tt>
- </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1231F"></a>A Quick Sample</h3></div></div><div></div></div><p>
-
-Below is a sample showing a simple usage of a controller test case (suite).
-All comments with a number are footnoted/explained in the area below the
-code sample.
- <pre class="programlisting">
-import com.jcorporate.expresso.services.test.*;
-import com.jcorporate.expresso.core.controller.*;
-import org.apache.commons.cactus.*;
-import org.apache.commons.cactus.util.*;
-import junit.framework.*;
-import org.w3c.dom.*;
-
-import java.net.HttpURLConnection;
-import java.io.IOException;
-import javax.servlet.*;
-import java.util.*;
-
-
-public class SampleControllerTest extends ControllerTestCase {
- public SampleControllerTest(String name) {
- super(name, "com.jcorporate.expresso.services.DBSecurityMatrix"); //1
- }
-
-
- public static void main(String[] args) throws Exception {
- junit.textui.TestRunner.run(suite()); //2
- }
-
- public static TestSuite suite() throws Exception {
- ControllerTestSuite cts = new ControllerTestSuite(); //3
- cts.addReadOnlySchemaDependency("com.jcorporate.expresso.core.ExpressoSchema"); //4
- cts.addTestSuite(SampleControllerTest.class);
- return CTS;
- }
-
-
- /* Executed on the client side of the web request */
- public void beginPromptState(WebRequest theRequest) throws Exception
- {
- super.logIn(theRequest); //5
- super.setupParameters("prompt",theRequest); //6
- }
-
- /* Executed on the server side of the web request */
- public void testPromptState() throws Exception {
- ControllerResponse response = super.controllerProcess(); //7
- assertTrue("Got a null response", response != null);
-
-
- assertTrue("Title returned from the controller state.",
- response.getTitle().length() > 0); //8
- }
-
-
- /*....Do as many test cases as you want, all with the public void signature */
-}
-
-</pre>
-<span class="bold"><b>Code explanations:</b></span>
- <div class="orderedlist"><ol type="1"><li><p>
-The second parameter to the ControllerTestCase's constructor is the name
-of the class you wish to test. In this case it's Expresso's own DBSecurityMatrix
-controller.
- </p></li><li><p>
-By writing a main method that calls JUnit's Text Test Runner, you have
-the ability to test out your classes and test cases by just running this
-class.
- </p></li><li><p>
-The controller test suite is responible for having a proper underlying
-test database running. If one doesn't exist, it will create it for you
-automatically, (including schemas), and if you need it to be erased when
-you're done, it will do that too.
- </p></li><li><p>
-This line(s) tells the test suite what schemas you must have up and running
-for your test case to work properly. To add more schemas, simply repeat
-the call for other schemas. Use addReadOnlySchemaDependency() if you DO
-NOT do any modifications to the underlying databases by running your controller.
-This will tell the system to not delete your created test database at the
-end of a run since it's still in pristine state. Call addSchemaDependency()
-if your controller modifies the underlying database in any way.
- </p></li><li><p>
-super.logIn() set's the appropriate cookies for a user Admin with a blank
-password. This is what is created by default in a test database.
- </p></li><li><p>
-The first parameter of setupParameters() is the name of the state that
-you will be testing with this test run. In this case it's "prompt". The
-function also sets the appropriate parameters for the Controller to return
-an XML formatted output.
- </p></li><li><p>
-The first confusing thing to know is that testXXXXXX() RUNS ON THE SERVER.
-Everything up to this point has been running on the client side. To process
-the controller, however, your job is simple, just call the ControllerTest
-case's controllerProcess() function and the testing framework will call
-your controller state automatically. This function will return a ControllerResponse
-object back to you, in effect, the data that the controller generated.
- </p></li><li><p>
-Once you get the ControllerResponse object you can walk through it's Inputs,
-Outputs, Blocks and Transitions to make sure they are as you would expect
-them to be. Use JUnit's assertTrue() and fail() functions to test if things
-were properly sent back.
- </p><p>
-You can take a look at the class
- <tt class="classname">com.jcorporate.expresso.services.controller.test.DBSecurityMatrixTests</tt>
-
-for a complete working controller test case that tests a couple of states
-including getting the results of a form POST.
- </p></li></ol></div>
- </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1234D"></a>Running The Test Case</h3></div></div><div></div></div><p>
-
-To run the Cactus tests you need the following software pieces.
- <div class="itemizedlist"><ul type="disc"><li><p>
-A database capable of dealing with more than one virtual machine connection.
-Sadly, this eliminates the possibility of using the Hypersonic Database
-that comes with Expresso as-is. There is a driver out there that uses RMI
-that allows more than one connection, but it is in a separate download
-available on the Internet.
- </p></li><li><p>
-A Servlet API 2.3 compliant servlet container. This includes containers
-such as Orion and the Tomcat 4 bundle that is included with the Expresso
-full download. If you only have a Servlet API 2.2 compliant container such
-as Tomcat 3, you need to separately download and install the Cactus jar
-for servlet api 2.2. Such downloads can be found at: http://jakarta.apache.org/commons/cactus/downloads.html
- </p></li></ul></div>
- </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N1235A"></a>Configuring Cactus</h4></div></div><div></div></div><p>
-
-There is one step that has to be done for Cactus to run properly on your
-system.
- <div class="itemizedlist"><ul type="disc"><li><p>
-Locate the file cactus.properties located in the WEB-INF/classes directory
-of your installation. Change the URL to the Cactus redirector servlet depending
-on your system. For most cases the URL will be very similar to what is
-listed already in the file. This allows Cactus to know where to send it's
-test case requests.
- </p></li></ul></div>
- </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N12364"></a>Running the test cases</h4></div></div><div></div></div><p>
-
- <div class="itemizedlist"><ul type="disc"><li><p>
-Before you can run your test cases. You must start your servlet engine.
-Otherwise the test case will fail when it goes to perform the server side
-code.
- </p></li><li><p>
-
-Run the class you are testing with the following Virtual Machine parameters:
- <pre class="programlisting">
--Djunit.argv.configDir=
--Djunit.argv.webAppDir=
--Djunit.argv.logDir=
-</pre>
-
-Be sure these parameters have the proper values set.
- </p></li></ul></div>
-
-You can run any JUnit test runner for a controller test case including
-SwingTestRunner for graphical test suites.
- </p><p>
-
-It should be noted that to follow Extreme Programming's (XP) unit testing
-strategies, you will want to chain your test cases together. Check the
-example of
- <tt class="classname">com.jcorporate.expresso.core.ExpressoTestSuite</tt>
-for a clear example of this usage. </p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1237A"></a>Performance Tests</h2></div></div><div></div></div><a name="N1237D" class="indexterm"></a><p>
-Conditions affecting the performance of an application can change over
-time. A server can get busier, a network can become more heavily loaded,
-a memory leak can manifest itself and so on. It is important that the performance
-of your application does not start off acceptable, and then as conditions
-change become no longer acceptable. Expresso has facilities to help you
-do this.
- </p><p>
-On the "Operation" page of Expresso is a link for maintenance of "Performance
-Tests". These entries allow you to specify a URL to be tested and to specify
-expected performance criteria for that URL. The URL does not actually have
-to be a part of an Expresso application - it can be any URL that you wish
-to verify is operational.
- </p><p>
-When the URL is first specified, you may not know what a reasonable performance
-is for that URL. The Performance Test table collects statistics as the
-tests are run that allow you see what the performance has been over a series
-of tests, so by running repeated tests at different times and viewing these
-statistics you can set reasonable values for the expected performance fields.
- </p><p>
-In addition to verifying that a specified URL runs and completes in a certain
-time, the Performance Tests table also allows you to check if the URL is
-returning an expected result. The "Expect String" field is used to specify
-a string of characters that is supposed to be a part of the output from
-the URL when it runs correctly. For a simple static web page, you can specify
-a few words of the text from the page. For a dynamic URL (such as a JSP
-or Servlet) you can give a term or two from the output that is expected.
-Be sure that the term specified would *not* occur if the page fails (e.g.
-avoid using HTML tags or something that might be part of an error message).
-In this way, the performance test is able to verify that this expected
-output is received, and to report a problem if it is not.
- </p><p>
-As each performance test is executed, it is timed: timing begins when the
-URL is requested and ends when the input stream ends. These times are compared
-to stored times to determine if the response was received in the expected
-time - the "normal" time for this test. In addition to the "normal" time,
-a "warning" time and a "max" time can be specified. Taking longer than
-the "max" time is considered an error, and the test fails. Taking longer
-than the normal time is reported as a caution, and longer than the warning
-time as a warning, but the test can still succeed.
- </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1238D"></a>Using Performance Tests</h3></div></div><div></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N12390"></a>Performance Tests Sets</h4></div></div><div></div></div><p>
-Performance Tests can be organized into "sets". These sets allow a sequence
-of tests to be executed one after another - ideal for situations where
-one result depends on a previous result - e.g. where sessions are used.
- </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N12395"></a>HealthCheck</h4></div></div><div></div></div><a name="N12398" class="indexterm"></a><p>
-HealthCheck provides a Controller to run one more test sets that are specifically
-indicated as being part of the periodic health check of the system. The
-test set has a flag that indicates if the set is to be used by HealthCheck.
- </p><p>
-Once you have defined a series of Performance Tests, the HealthCheck utility
-is used to run them periodically. This can most easily be done by setting
-up a shell script or batch file that is executed by your operating system's
-task scheduler (cron, System Scheduler ,etc) on some specified schedule.
-For example, the script for a Linux system can look like this:
- </p><pre class="programlisting">1. #!/bin/sh
-
-2. java com.jcorporate.expresso.core.utility.ControllerRun
-
- configDir=/home/expresso/expresso/expresso-web/WEB-INF/config
-
- webAppDir=/home/expresso/expresso/expresso-web db=site
-
- controller=com.jcorporate.expresso.ext.controller.HealthCheck
-
- state=health</pre><p>
-The line beginning with "java" is all one line in the actual shell script,
-broken across multiple lines here for clarity.
- </p><p>
-This script can then be executed, for example, every hour via the "cron"
-utility by specifying a crontab entry like this:
- </p><pre class="programlisting">1. SHELL=/bin/sh
-
-2. MAILTO=root
-
-3. 0 * * * * healthcheck.sh</pre><p>
-When HealthCheck runs, it reads the list of Performance Sets that are flagged
-for inclusion in the HealthCheck and executes them, collecting performance
-statistics as it goes. If any URL does not return the specified "Expect"
-string, or takes too long to run, it builds an email to be used to send
-an "Event" notification. The event code "HEALTH" is used to determine who
-should receive the notification, which looks like this:
- </p><pre class="programlisting">From: support at javacorporate.com
-
-Sent: Tuesday, March 27, 2001 12:01 PM
-
-To: mnash at javacorporate.com
-
-Subject: ERROR:System Health Check
-
-HealthCheck
-HealthCheck at 2001-03-27 08:00:11
-
-For database/context 'default'
-There were no failures, no warnings, and 1 caution,
-CAUTION: Test 6 (Center for Expresso) for URL
-
-'http://www.jcorporate.com/components/
-
- internal/Center.jsp?category=65'
-
-responded slower than it's set normal time of 160 milliseconds.
-
-It ran in 237 milliseconds.
->From Server:www.jcorporate.com,
- Database/context:default (Default Database)</pre><p>
-The above example shows the message received when a particular URL went
-over it's Normal Time, but not over it's Warning time, and still executed
-successfully (e.g. returned the string specified).
- </p><p>
-Part of the usefulness of the HealthCheck process is that it does generate
-an email even if there were no warnings or cautions - this email is a "success"
-Event, so you can easily opt to only see a message when there *is* a problem,
-but the success emails arriving on schedule are a good indicator that all
-is well with the site. The one error condition that HealthCheck of course
-cannot catch is when the entire server is down - preventing HealthCheck
-from running - or when the email server is unable to deliver it's warnings.
-If you know, however, that you should be getting an email once an hour,
-or whatever the appropriate schedule is, then you can take action if you
-notice that it has not arrived.
- </p><p>
-HealthCheck generates a system event 'HEALTH', which is emailed to all
-subscribed users automatically. The event's "success" code is true if the
-health check encountered no cautions, warnings, or errors, and false otherwise.
- </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N123B5"></a>RunTests</h4></div></div><div></div></div><p>
-The RunTests controller is used to execute one or more test sets. It has
-the ability to run a sequence of test sets, and to run that sequence multiple
-times, and optionally to run multiple threads of tests at once. This allows
-load on the system to be simulated, catching performance errors and problems
-that only occur under load.
- </p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N123BA"></a>Optimizing Performance</h2></div></div><div></div></div><p>
-It is important to concentrate your efforts on the areas where the largest
-gain can be experienced - in order to do this, you must understand where
-the "hot spots" are in your application. Expresso can help you do this,
-and then help you perform more extensive analysis of those "hot spots"
-to make sure they are running as quickly as possible.
- </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N123BF"></a>Performance Hogs</h3></div></div><div></div></div><p>
-There are a number of things that can slow down an Expresso application.
-By checking this list carefully before beginning any more intensive performance
-tuning, you can verify that you are not "driving with the parking brake
-on" and can often solve performance problems immediately.
- </p><a name="N123C4" class="indexterm"></a><p>Some of the items to watch for are:</p><a name="N123CC" class="indexterm"></a><a name="N123D2" class="indexterm"></a><div class="itemizedlist"><ul type="disc"><li><p>Logging</p><p>
-Log4j, which is the integrated logging mechanism built into Expresso, is
-a very capable package, and it's performance impact is very small compared
-to many logging methods. Still, the fastest logging is no logging at all,
-and careful adjustment of the expressoLogging.xml file, and the corresponding
-file for your custom application can result in a large performance benefit.
- </p><p>
-The first logging issue to look for is of course to select the appropriate
-logging level for your running application. If you are still testing and
-debugging, then log priorities of "debug" for at least some objects might
-be appropriate, but in a production environment you should need no more
-than "info", and preferably only "warn". One of the easiest ways to see
-if you have something set to too detailed a level is to read the log file,
-looking for "debug" or "info" messages that you do not really need to see
-in production - then find out why these messages are still enabled and
-edit the xml configuration file accordingly.
- </p><p>
-Another important logging performance issue is the format of the logging
-message: the "ConversionPattern" parameter that can be supplied when setting
-up a logging channel can have a significant impact on performance. During
-testing and debugging, it is often very useful to be able to see the exact
-class, method, and line number that a log message originated from. Unfortunately,
-during production the processing required to produce this information is
-very expensive, and can be the cause of a performance issue. Review the
-log4j documentation included with Expresso for details on how to specify
-less "expensive" patterns for logging entries for production systems.
- </p></li><li><p>dbTest on</p><p>
-In the property file, the dbTest property supplies an SQL statement that
-is used to verify if a database connection is "alive" (e.g. connected to
-the database and operational) before passing the connection back from the
-connection pool when a new connection is requested. This is helpful in
-situations where the connection could time out or otherwise become unavailable
-while the connection pool is still maintaining the connection - for example,
-an external data warehouse connection that is only used infrequently. In
-normal production, however, this option can be expensive, particularly
-if the query being specified is not very fast on that particular database.
-For example, if you specified a dbTest of "select * from USERLOGIN" you
-would certainly notice a <span class="emphasis"><em>sever</em></span> performance decrease,
-as the entire USERLOGIN table would be retrieved every time a new connection
-was requested (which is a great many times).
- </p><p>
-Ideally, leave out the dbTest property where it's not needed, or at least
-be sure that it is a fast operation for the specific database.
- </p></li><li><p>dbCache off</p><p>
-In the properties file, the dbCache property is by default "y", e.g. database
-object caching is enabled. It is possible to specify dbCache=n, which disables
-caching for database objects entirely, and as a result does not take advantage
-of caching as a performance boost for database accesses. Be sure you leave
-out "dbCache=n" for best production performance.
- </p></li><li><p>Bad Setup Values</p><p>
-For best performance, it is important to review your Setup values for correctness.
-For example, if you should have specified an email server that is incorrect
-our outside your local network, your application could be spending a lot
-of fruitless CPU cycles trying to attach to this server to send email notifications.
- </p><p>
-The best way to catch such problems is to review the log, looking for any
-unusual errors or warnings and tracking them back to their source. Often
-the culprit will be a bad Setup value.
- </p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N123F8"></a>Cache Tuning</h3></div></div><div></div></div><a name="N123FB" class="indexterm"></a><p>
-Unless you have specifically turned off the option to do so, (see the properties
-file documentation) Expresso as it runs will collect information about
-the effectiveness of the DB Object caching system. This information includes
-how many read operations (retrieve(), searchAndRetrieve(), find() and so
-forth) have been made for a particular DB object (in a given db/context),
-and how many of these reads were able to use the cache to find the record
-they were looking for. The idea of course, is that generally speaking the
-more often the record can be read from cache, instead of being retrieved
-from the database, the faster your application will run.
- </p><p>
-The "Status" servlet is used to retrieve this information, which also computes
-the percentage of "hits" to the database object that were supplied by the
-cache - what you're looking for in this listing is a large number of total
-hits with a low percentage (or zero percentage) of hits to the cache. This
-indicates a DBObject that is heavily used by read operations in your application,
-but which is not caching very much. The listing from status also shows
-you the size of the currently specified cache for this database object
-- if it is zero, then you may not have an entry for the object in the "Database
-Object Page Limits" table (accessed from the "Setup" page in Expresso).
- </p><p>
-There are a number of other factors you should consider when tuning caching
-for database objects:
- </p><div class="itemizedlist"><ul type="disc"><li><p>Available Memory</p><p>
-Caching can use substantial amounts of memory, so you should check the
-amount of available memory to your application before increasing the cache
-sizes for objects too much. You can see a "snapshot" of current memory
-usage from the status servlet, but you may wish to read the log to see
-what memory usage has been over time. You can adjust the logging detail
-level for the "core.cache.CacheManager object" to see periodic memory reports.
-If you see a number of instances where the cache manager is having to clear
-caches in order to get more memory (e.g. to bring it over the specified
-minimum - again see the property file documentation for details), then
-you probably cannot increase caching much without actually slowing down
-the application.
- </p><p>
-Be sure that you are launching your java virtual machine (or your applications
-server) with the appropriate options to make enough memory available to
-your application - just because you physically have enough memory in your
-system doesn't mean that your JVM has use of this memory. See the -X options
-for your Java runtime for details on how to increase this limit.
- </p></li><li><p>Cached Items</p><p>
-Some database objects may show high activity, and low cache hits, but still
-not be a problem. This is particularly true of items that are <span class="emphasis"><em>always</em></span>
-cached by Expresso, such as Setup values, security entries for db objects
-and controllers, and a few others.
- </p></li><li><p>Write Patterns</p><p>
-The effectiveness of caching is also influenced by the patterns in which
-your application writes to the database - if a particular db object is
-changed, it's cache entry is removed (so that stale data is not read) and
-it must be read from the database again the next time it is accessed. If
-you have an object that has a lot of cache set up for it, but is still
-not caching very successfully, it may be that this object is being written
-to very frequently.
- </p><p>
-This is more of an application design issue than something that can be
-directly addressed by cache tuning.
- </p></li></ul></div><p>
-By careful manipulation of the records in the "Database Object Page Limit"
-table, you can make best use of your available memory via db object caching.
-This is often the single most important optimization step you can take.
- </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N12420"></a>Database Optimization</h2></div></div><div></div></div><p>
-If all of the above optimization and performance tuning techniques indicate
-that there is a problem with database access slowing down the system (despite
-tuning the db cache), then it is sometimes required to analyze the database
-queries themselves in order to determine which queries are causing the
-problem.
- </p><p>
-The DBConnection object, which is responsible for executing the actual
-SQL queries built by DB objects, can help perform this analysis: turn on
-the logging priority for this object to "debug" using the expressoLogging.xml
-file, and monitor the results. Each SQL query will have it's elapsed time
-recorded, and you can use this information to pick out the worst offenders
-and either modify your application to perform better queries, or use database
-indices to make them faster.
- </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N12427"></a>Indexing</h2></div></div><div></div></div><p>
-See the section on DBobjects for information about setting up Indexes for
-faster access on non-primary-key fields.
- </p></div><p></p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1242D"></a>Conclusion</h2></div></div><div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N12430"></a>Contributors</h3></div></div><div></div></div><p>
-
-The following persons have contributed their time to this chapter:
- <div class="itemizedlist"><ul type="bullet"><li style="list-style-type: disc"><p>
-Larry Hamel <a href="edg_intro.html#jgroup" title="Jcorporate's JGroup Services">(JGroup Expert)</a>
- </p></li><li style="list-style-type: disc"><p>Mike Nash</p></li><li style="list-style-type: disc"><p>Mike Rimov</p></li><li style="list-style-type: disc"><p>
-Mike Traum <a href="edg_intro.html#jgroup" title="Jcorporate's JGroup Services">(JGroup Expert)</a>
- </p></li></ul></div>
- </p></div><p>
-
- <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p><a name="donate_operation"></a>
-Was this EDG documentation helpful? Do you wish to express your appreciation
-for the time expended over years developing the EDG doc? We now accept
-and appreciate monetary donations. Your support will keep the EDG doc alive
-and current. Please click the Donate button and enter ANY amount you think
-the EDG doc is worth. In appreciation of a $35+ donation, we'll give you
-a subscription service by emailing you notifications of doc updates; and
-donations $75+ will also receive an Expresso T-shirt. All online donation
-forms are SSL secured and payment can be made via Credit Card or your Paypal
-account. Thank you in advance.
- </p><p>
-<a href="http://www.jcorporate.com/edgdoc.html" target="_top"> <span class="inlinemediaobject"><img src="../images/edg/paypal.bmp"></span> </a>
- </p></div>
- </p><p>
-Copyright © 2001-2004 Jcorporate Ltd. All rights reserved.
- </p></div></div><div class="navfooter"><hr><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="edg_deploy.html">Prev</a> </td><td align="center" width="20%"><a accesskey="u" href="edg_index.html">Up</a></td><td align="right" width="40%"> <a accesskey="n" href="edg_jobcontrol.html">Next</a></td></tr><tr><td valign="top" align="left" width="40%">Chapter 19. Expresso Component Application Deployment </td><td align="center" width="20%"><a accesskey="h" href="edg_index.html">Home</a></td><td valign="top" align="right" width="40%"> Chapter 21. Jobs Expresso</td></tr></table></div></body></html>
\ No newline at end of file
More information about the cvs
mailing list