Added help for debug screens.

lib/python/Products/OFSP/help/DebugInfo-Debug.dtml

+<dtml-var standard_html_header>
+
+<h1>Debugging Information</h1>
+
+<p>        Zope provides a simple debugging interface to help
+        product authors find memory leaks in their products
+        as well as Zope itself.  There is a special
+        object available to users with sufficient access
+        to use the control panel.  From the Control Panel, 
+        click the <code>Debugging information</code> link.</p>
+
+<p>        The following information is displayed:</p>
+<ul><li><p>The Zope version</p>
+
+</li>
+<li><p>The Python version</p>
+
+</li>
+<li><p>The system platform name</p>
+
+</li>
+<li><p>The ID number of the Zope process
+                (if available on your platform)</p>
+
+</li>
+<li><p>The length of time Zope has been running</p>
+
+</li>
+<li><p>The top refcounts, including a table listing
+                the changes since the last snapshot</p>
+
+</li>
+<li><p>The open object database connections</p>
+
+</li></ul>
+
+<p>        The Zope version, Python version, and system
+        platform name are used to
+        verify compatibility between Zope, Python,
+        and your system.  On platforms
+        where the process ID number is available,
+        the Zope process can be managed
+        using a more forceful means than is available
+        through the web.</p>
+
+<p>        The top refcounts list lets you take a look
+        at what is being stored by
+        Zope in memory.  The scrollable list shows
+        how many instances of each
+        type of object are currently in memory.</p>
+
+<p>        If there are items in the list with a very
+        high refcount, there is a good chance there
+        is a memory leak in a product or in Zope.  Memory leaks,
+        which cause Zope to take up excessive amounts of RAM,
+        are not likely to occur as often in the Python language
+        as they do in languages that do not have a garbage
+        collector.  But memory leaks
+        still occur when a reference to an object is kept
+        even after the object is no longer useful.</p>
+
+<p>        The following example illustrates a simple reference
+        to an object that is no longer needed:</p>
+<PRE>
+                helloString = 'Hello, %s!'
+                name = ''
+
+                def printHello():
+                        print helloString % name
+
+                def printHelloWorld():
+                        global name
+                        name = 'World'
+                        printHello()
+
+                printHelloWorld()
+
+</PRE>
+
+<p>        <code>printHelloWorld()</code> sets a variable for the module
+        then calls <code>printHello()</code>.
+        The problem is that module variables, such as <code>name</code>,
+        are never cleaned up by the garbage collector.
+        The <code>name</code> object, which in this case is just a string but
+        could be an image or a DTML method, is kept in memory until
+        the Python process exits.  Under normal circumstances,
+        the Python process that runs Zope exits only when
+        stopped, which could mean months of continuous usage.</p>
+
+<p>        There are many other circumstances where unnecessary
+        references can be accidentally held.  Finding the cause
+        of a memory leak can be a major task.  Look for books
+        and mailing lists on http://www.python.org .</p>
+
+<p>        The table below the list is designed to assist in
+        locating a specific memory leak.  The "Update Snapshot"
+        link just below the table will take
+        the current refcounts and store them in memory.
+        Then each time the debugging page is reloaded, the
+        table will show the difference in
+        refcounts between the snapshot and the current state.</p>
+
+<p>        If your product is causing memory leaks,
+        take a snapshot before the memory leak occurs,
+        do whatever it is that seems to cause the leak,
+        then reload the debugging page.  You should see which
+        type of object is is taking up excessive RAM.
+        Then check for the leak in the sections of your
+        code that deal with that type of object.</p>
+
+<p>        Finally, the debugging page shows a list of currently
+        open database connections.  In Zope 2.x a database
+        connection usually corresponds
+        with an HTTP request.  The left column shows the
+        time at which the connection was opened.  If there
+        is a request that has been running for a long
+        time you may need to restart Zope to kill the
+        corresponding thread. The middle column usually
+        shows the state of the REQUEST object with size
+        of the cache for that connection in parentheses.
+        The right column shows
+        information about the version the user is working in.
+</p>
+
+<dtml-var standard_html_footer>
+
+

lib/python/Products/OFSP/help/DebugInfo-Profile.dtml

+<dtml-var standard_html_header>
+
+<h1>Profiling Information</h1>
+
+<p>        Zope can provide real-time profiling information.
+        Profiling helps product authors to speed up sections
+        of code that are taking too long
+        to perform their tasks.  In order to use profiling,
+        Zope has to be started with the <code>PROFILE_PUBLISHER</code>
+        environment variable set to a non-empty value. If the variable
+        is set to a valid filesystem path, then the accumlated profile
+        information will be dumped to the named file when Zope is shut
+        down. If the variable is simply set to a non-empty value that 
+        is not a valid filesystem path then Zope will still run in 
+        profiling mode, but profile information will only be available
+        through the web interface.
+        </p>
+
+<p>        Once Zope has started in profiling mode (note that profiling
+        will slow Zope performance significantly), use your site with
+        your Web browser - Zope will accumulate profiling information
+        as you are working with your site.  When you want to view the
+        profiling information, visit the Control Panel, click on the 
+        <code>Debugging information</code> link and select the <code>Profiling</code> tab.</p>
+
+<p>        The profiling screen will show a list of methods and the amount 
+        of time each method is taking. Multiple views are available by 
+        changing the sort order and pushing the "update" button. The  
+        online profiler is based on the standard Python profile module. 
+        For specific information on the meaning of the profile information,
+        see the standard Python documentation for the profile module.
+</p>
+
+<dtml-var standard_html_footer>