Abstract:
In the system of the present invention, the performance of distributed window systems which employ shared libraries is provided. A shared library is a library which is referenced and accessed by multiple processes. Synchronization events are preset in a journal file which, during playback of the same, trigger a mechanism which reads the page table of the current applications. Once the playback is complete, the page table measurements taken during playback are reviewed and information is extracted which is used to determine the working set for shared libraries. Using the working set, the number of pages referenced and the rate of reference can be used to improve performance and predict behavior of other systems.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The system of the present invention is related to the field of benchmarking of computer systems and computer software. Specifically the system of the present invention relates to the field of benchmarking of window based systems. 
     2. Related Applications 
     This application is related to copending U.S. patent application Ser. No. 07/498,206, filed Mar. 23, 1990, entitled &#34;Synchronized Journaling System&#34;, and U.S. patent application Ser. No. 07/411,036, filed Sept. 21, 1989, entitled, &#34;Method and Apparatus for Extracting Process Performance Information from a Network&#34; and are herein incorporated by reference. 
     3. Art Background 
     The term &#34;benchmarking&#34; is used to describe a series of tests performed on a computer system which simulate various operations that may be performed by a user of the system. During the execution of tests, various measurements are taken. These tests are performed on the system a number of times and the results of the measurement taken are compared with optimum or other results recorded during benchmarking of similar systems. 
     Through the use of benchmarking, a systematic method is provided to test and measure the performance of systems in a controlled manner. With the advent of window based systems such as those manufactured by Sun Microsystems, Inc., Mountain View, Calif., it has become necessary to provide a means of testing the performance capability of such window systems and the computer software and hardware that implement the window systems. An example of early benchmarking of window systems is described in Gaylin, &#34;How Are Windows Used? Some Notes on Creating An Empirically Based Windowing Benchmark Task&#34;, CHI Proceedings (April 1986), pages 96 to 100. 
     Window systems present additional factors which must be considered in evaluating system performance. For example, a distributed window system consists of multiple processes, including the application or client processes, the window server and optionally a window manager. The application processes are really client processes which are operated through the window system. The window server controls the display and mediates access to display by the client&#39;s process. It also provides a base functionality in terms of windows and cursors and determines how to draw into these windows and how to distribute events to them. Examples of window systems include the X11™ (X11 is a trademark of the Massachusetts Institute of Technology) which supports the X11 protocol (See Sheifler, Gettys, &#34;The X Windows System&#34;, ACM Transactions On Graphics, Vol. 5, No. 2 (April 1986) pp. 79-109) and X11/NeWS system, available from Sun Microsystems, Inc., Mountain View, Calif., which supports both the X11 and NeWS™ window server protocols (NeWS is a trademark of Sun Microsystems, Inc.) (See Shaufler, &#34;X11/NeWS Design Overview, Proceedings of the Summer 1988 User Conference, (1988) pp. 23-35). 
     The client process is typically linked with a &#34;toolkit&#34; which implements the user interface functionality and provides the means for the client process to tailor the user interface to the client process. The toolkit determines how the window systems menus look, how users interact with control areas and how control areas are organized. Furthermore, the toolkit provides a programmatic interface that allows developers of the application programs to implement sophisticated windowing applications. An example of a toolkit is the XView™ toolkit (XView is a trademark of Sun Microsystems, Inc.) available from Sun Microsystems, Inc., for the X11NeWs Window System. For further information, see Jacobs, &#34;The XView Toolkit, An Architectural Overview&#34;, 3rd Annual Technical Conference, (1989). 
     The window manager may be a separate process as is typically the case with the X11 protocol or it may be part of a window server as is the case with respect to the X11/NeWS window system where the window manager is a collection of processes that reside in the window server. The window manager controls the workspace, the window that occupies the entire screen and determines the workspace menu window and icon placement. 
     In a kernel-based window system, the kernel is modified to include an event manager and a means to contain window state information. This portion of the system is in charge of the input/output devices and of distributing events to application processes. The kernel-based window system also consists of a user interface toolkit which provides the applications&#39; menus, control areas and drawing capabilities. An example of a kernel-based window system is the SunView™ window system (SunView is a trademark of Sun Microsystems, Inc., see Sun Microsystems Inc., SunView 1 Programmer&#39;s Guide, revision A, (5/9/88) and Sun Microsystems, Inc., SunView 1 Systems Programmer&#39;s Guide, revision A, (5/9/88)). 
     In order to provide an accurate benchmark of the system, it is desirable to simulate as closely as possible a user session in which the user performs a variety of tasks on the system. A technique was developed to provide this type of benchmark referred to as journaling. Journaling is a method for recording events reflective of a series of user actions in a session file referred to as a &#34;journal file&#34;. The file is subsequently read and the actions initiated and executed in the sequence recorded in the file, thereby providing an automated means for simulating the user session (See, e.g., CAPBAK/UNIX Terminal Session Capture and Playback for UNIX Systems, Software Research Incorporated, (1989)). 
     Window based systems introduce additional actions to consider when developing a benchmark for the system. A window based system consists of a number of input devices used concurrently and number of processes which interact with one another in a pre-determined sequence in order to produce the desired effect, such as selecting a client or application process from a menu or moving the cursor from one window to another. In an attempt to maintain the proper sequence of execution, a time delay between various actions is recorded in the journal file in addition to the other information recorded to simulate a user session. By scaling the time between events, it is possible to propagate events through the system faster on playback than on record. However, playing events faster than the speed at which they were initially recorded can lead to unexpected behavior. This unexpected behavior arises because of race conditions caused by one process executing prior to the uncompleted execution of another process, the final state of which is utilized by the subsequent process. 
     A method was developed using special events marking the locations in the journal file where previously initiated processing must be completed before initiating a subsequent process. These special events are referred to as synchronization events and are typically defined at locations where multiple processes are exchanging state. These synchronization events are put into the journal sessions during the recording phase. On playback, the journaling mechanism waits for each of these synchronization events to occur before proceeding through the journal file and initiating subsequent events in the window system. (See Islam, Ingoglia, &#34;Testing Window Systems&#34;, Interfaces, Systems and People Working Together, 28th Annual Technical Symposium, ACM, Washington, D.C. (1989) pp. 95-103; and copending U.S. patent application Ser. No. 07/498,206, filed Mar. 23, 1990, entitled &#34;Synchronized Journaling System&#34;). 
     There are a variety of parameters or metrics employed to measure the performance of a computer system, such as the speed of execution of a process and the output generated during execution of a process. Another metric used to measure the performance of a computer system is the measurement of the size of the working set of a process. The working set is the number of memory pages referenced during execution of a process. The working set size is indicative of the processing speed because the more pages referenced, the greater occurrence of paging. Paging is a time consuming process in which a page of information is swapped into and/or out of fast memory. 
     The working set is measured at predetermined time intervals and the working set size is compared to measurements taken at prior intervals to determine the performance of the system. One such system is described in copending U.S. patent application Ser. No. 07/411,036, filed Sept. 21, 1989, entitled &#34;Method and Apparatus for Extracting Process Performance Information From a Network&#34;. Time-dependent measurements (i.e., measurements performed during predetermined time intervals) perform adequately in traditional non-window-based systems because the execution sequence is primarily controlled by the system providing a predictable temporal system in which the time based measurements can be set to measure the system performance during different portions of process execution. 
     However, in window-based systems, the system is user interactive and event driven. Thus, the system no longer executes in a manner that is time predictable and time-based measurements do not always occur in predictable portions of process execution. In addition, some window systems, such as X11/NeWS, include shared libraries which are jointly referenced by multiple processes. In window systems which employ shared libraries, it is also preferred that the performance on the system relevant to usage of shared libraries is measured. 
     SUMMARY OF THE INVENTION 
     It is the object of the present invention to provide an improved mechanism to benchmark window-based systems. 
     It is an object of the present invention to provide a benchmark mechanism to operate in an event-driven system. 
     It is therefore an object of the present invention to provide the performance measurement of window based systems which employ shared libraries between client processes. 
     It is a further an object of the present invention to provide a system for benchmarking window systems which operate in a distributed environment. 
     In the system of the present invention, a means for measuring the performance of event-driven systems, particularly distributed window systems which employ shared libraries, is provided. Synchronization events are preset in a journal file which, during playback of the same, trigger a paging analysis tool to read the page table of the current application processes. Once playback is complete, the page table measurements taken during playback are reviewed and information is extracted which is used to determine the working set for private memory and shared libraries. Using the working set, the number of pages referenced and the rate of reference can be used to improve performance and predict the performance behavior of a system. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The objects, features, and advantages of the present invention will be apparent from the following description of the invention in which: 
     FIG. 1 is a typical computer based system for implementing the window-based measuring device of the present invention. 
     FIG. 2 is a block diagram functional representation of the system of the present invention. 
     FIG. 3 is flowchart illustrating the benchmarking process. 
     FIG. 4 is an illustrative script demonstrative of a user session. 
     FIG. 5 is an illustrative script demonstrative of a user session which includes synchronization events and events used to copy and clear the page tables. 
     FIG. 6 is an ASCII text version of a journal file including synchronization events and events to copy and clear the page tables. 
     FIG. 7 illustrates page tables read and stored in a file. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Notation And Nomenclature 
     The detailed descriptions which follow are presented largely in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. 
     An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. These steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. 
     Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention; the operations are machine operations. Useful machines for performing the operations of the present invention include general purpose digital computers or other similar devices. In all cases there should be borne in mind the distinction between the method of operations in operating a computer and the method of computation itself. The present invention relates to method steps for operating a computer in processing electrical or other (e.g., mechanical, chemical) physical signals to generate other desired physical signals. 
     The present invention also relates to apparatus for performing these operations. This apparatus may be specially constructed for the required purposes or it may comprise a general purpose computer as selectively activated or reconfigured by a computer program stored in the computer. The algorithms presented herein are not inherently related to a particular computer or other apparatus. In particular, various general purpose machines may be used with programs written in accordance with the teachings herein, or it may prove more convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will appear from the description given below. 
     General System Configuration 
     FIG. 1 shows a typical computer-based system for benchmarking of window-based systems according to the present invention. Shown there is a computer 101 which comprises three major components. The first of these is the input/output (I/O) circuit 102 which is used to communicate information in appropriately structured form to and from the other parts of the computer 101. Also shown as a part of computer 101 is the central processing unit (CPU) 103 and memory 104. These latter two elements are those typically found in most general purpose computers and almost all special purpose computers. In fact, the several elements contained within computer 101 are intended to be representative of this broad category of data processors. Particular examples of suitable data processors to fill the role of computer 101 include machines manufactured by Sun Microsystems, Inc., Mountain View, Calif. Other computers having like capabilities may of course be adapted in a straightforward manner to perform the functions described below. 
     Also shown in FIG. 1 is an input device 105, shown in typical embodiment as a keyboard. It should be understood, however, that the input device may actually be a card reader, magnetic or paper tape reader, or other well-known input device (including, of course, another computer). A mass memory device 106 is coupled to the I/O circuit 102 and provides additional storage capability for the computer 101. The mass memory may include other programs and the like and may take the form of a magnetic or paper tape reader or other well known device. It will be appreciated that the data retained within mass memory 106, may, in appropriate cases, be incorporated in standard fashion into computer 101 as part of memory 104. 
     In addition, a display monitor 107 is illustrated which is used to display messages or other communications to the user. Such a display monitor may take the form of any of several well-known varieties of CRT displays. A cursor control 108 is used to select command modes and edit the input data, and in general provides a more convenient means to input information into the system. 
     Process Description 
     The system of the present invention measures the working set of the system to determine the performance of the distributed window system according to events which occur during execution of processes by the system. A synchronized journaling mechanism is used in conjunction with a paging analysis tool to perform paging analysis at predetermined points during execution of a sequence of events representative of user actions which simulate a user session in a window-based system. 
     The working set is the set of all pages in memory referenced during the execution of a process. The amount of paging performed during execution of the process is a significant factor which effects system performance because paging is a time consuming process in which pages of information are swapped in and out of memory. The more paging that is performed, the longer the execution time of the process. 
     It has been found that the utilization of shared libraries by multiple processes increases system performance. Processes that utilize shared libraries can share the pages that belong to the libraries, thereby decreasing the amount of paging required during process execution. Increased performance has been found when shared libraries have been implemented into window systems. In window based systems, the libraries which form the windows system toolkit can be structured to be shared as it is structured in the X11/NeWS window system. To further increase performance of the system, it is desirable to measure the paging which occurs with respect to the shared libraries. 
     An event driven synchronized journaling mechanism is used in performing the benchmark. Synchronization events are installed into the journal file at predetermined points where processing for a second event is dependent upon the completion of execution of processing for a first event. The synchronized journaling mechanism controls the progress through the journal file by halting initiation of events subsequently listed in the journal file and waiting until certain specified synchronization events occur before proceeding to the next action to be initiated and executed. Thus the execution speed of the text can be increased during playback, the proper states can be maintained between multiple processes which interact and exchange state with one another, and the errors which arise due to race conditions can be avoided. The synchronized journaling mechanism is described is Islam, Ingoglia, &#34;Testing Window Systems&#34;, Interfaces: Systems and People Working Together, 28th Annual Technical Symposium, ACM, Washington, D.C., pp. 95-103 (1989), and copending U.S. patent application Ser. No. 07/498,206, filed Mar. 23, 1990, entitled, &#34;Synchronized Journaling System&#34;. 
     A paging analysis tool is integrated with the synchronized journaling mechanism to provide an event driven journaling system which measures the working space of the system at predetermined points during the execution of the texts which form the benchmark. The paging analysis tool accesses the memory management unit of the computer system, reviews the page tables which comprise the address space of the system and determines those pages that have been referenced during system operation. Preferably, a paging analysis tool such as the one described in U.S. patent application Ser. No. 07/411,036, filed Sept. 21, 1989, entitled &#34;Method and Apparatus for Extracting Process Performance Information From a Network&#34; is used. In this paging analysis tool, a duplicate or back copy of the page table of each monitored process is maintained. Thus, whenever the page tables are changed according to read, write or paging operations, the changes are subsequently recorded in the back copies. The back copies are accessible and controllable by the paging analysis tool throughout the benchmark. Although, the following description of the preferred embodiment describes operations in which the back copies of the page tables are read, it will be apparent to one skilled in the art that the system of the present invention equally applies to paging analysis tools in which the page tables are read and cleared. 
     The journaling mechanism controls the operation of the paging analysis tool to indicate when the address space is to be examined to calculate the working set for a particular section of the benchmark. This is illustrated by FIG. 2. The synchronized journaling mechanism 200 reads the journal file and initiates the events as listed in sequence. In the present illustration, the events include executing processes 205, 210, 215, as part of the benchmark. In addition, the synchronized journaling mechanism communicates with the paging analysis tool 220 to read the page tables (in the preferred embodiment, a back copy of the page tables) at predetermined points during initiation of events listed in the journal file and store copies of the page tables in a file 225. 
     Preferably a separate connection is provided to establish communications between synchronized journaling mechanism and the paging analysis tool. For example, in the UNIX® operating system (UNIX is a registered trademark of AT&amp;T), a &#34;socket-connection&#34; can be opened between processes which establishes a channel for communicating bits of information between processes. For further information regarding socket connections, see J. Bach, The Design of the UNIX Operating System, (Prentice-Hall, 1986) pp. 283-388. Thus, in the preferred embodiment, the synchronizated journaling mechanism opens a socket connection to the page analysis tool to transmit commands to the page analysis tool and to receive signals from the paging analysis tool. 
     Two events are provided in the synchronized journaling mechanism which, when executed, transmit commands to the paging analysis tool. The first, referred to as the clear page tables or &#34;dehat&#34; command, clears the back copies of the page tables maintained for each process in the memory management unit of the computer system. The second, referred to as the read page tables or &#34;snapshot&#34; command reads the back copies of the page tables from the memory management unit and copies the tables into a file for subsequent review and analysis. These commands incorporate synchronization events such that progression through the journal file is halted and subsequent events in the journal file are not initiated until execution of the commands is complete, thereby ensuring the measurements taken accurately reflect the state of the page tables at the location in the journal file where the command is located. 
     Once the execution of the last process listed in the journal file is finished, the replay sequence is complete and the synchronized journaling mechanism initiates a process to analyze the page tables read and copied to storage to compute the working set for each page table, thereby providing paging information regarding both private and shared files which are indicative of the performance of the system during the benchmark. 
     The paging analysis tool is modified to receive and execute the commands issued by the synchronized journaling mechanism. Furthermore, the paging analysis tool is modified to output a signal to the synchronize journaling mechanism to indicate that execution of the command is complete and the journaling mechanism may continue initiating the actions listed in the journal file. 
     The process of computing the working set for systems which utilized shared libraries is illustrated by the flowchart of FIG. 3. At block 250, a journal file is created. The journal file may be created by &#34;capturing&#34; an actual user session during which a user performed a variety of tasks. Preferably the journal file is created by capturing a user session which follows a script of user actions reflective of a typical user session on the computer system. An example of a script file which provides instructions regarding the user actions to perform as part of the benchmark is illustrated by FIG. 4. This script file shows a simple user session in a window based system in which the user starts a plurality of applications or client processes, including &#34;console&#34;, &#34;cmdtool&#34;, &#34;textedit&#34; and &#34;mailtool&#34;, and performs a variety of tasks, including, opening and closing windows, moving between windows and changing the focus from one window to another, as well as performing a variety of tasks within the client processes initiated. 
     The events codes generated when actions are taken which are representative of the actions executed by the user to perform a task, for example, moving the cursor to a window, clicking a button on the mouse to change the focus in the window system to the current window and clicking on an icon resident in the current window to perform a certain task, are captured as the event code is transmitted to the components of the computer system which execute the action. Thus the actions can easily be re-initiated by outputting the same event code from the journal file during replay. Alternatively, the journal file can be simply created by manually inputting the event codes representative of actions to be executed to perform certain tasks. The synchronized journaling mechanism subsequently &#34;replays&#34; the events representative of user actions contained in the journal file wherein each action listed is initiated in sequence and executed thereby simulating the user session. 
     Preferably, the events representative of actions to be performed which are captured and stored in the journal file are in the XDR format which is a binary format standard used across multiple computer architectures. (For information regarding the XDR format, see Sun Microsystems, Inc., Network Programming, revision A, (5/9/88)). Alternatively, the journal file may be stored in ASCII text format such that the journal file is portable across different computer systems and the user can easily review and modify the journal file as needed to customize a journal file or fine tune the actions executed to provide further insight into the performance of the computer systems on which the benchmark is performed. For example, the format of each event in the journal file may be: 
     
         timestamp×y keystroke nameofevent, 
    
     Where the timestamp records the time when the event occurred, the x, y fields record the coordinates of the pointer at the time of the event, the keystroke field represents the state of the keys or keystrokes (it is null for mouse events) and the nameofevent field stores the name or class of the event. However, the system is not limited as such and the codes stored in the journal file can be in any format understandable by the journaling mechanism such that during replay, the events listed in the journal file representative of user actions are initiated and executed. 
     Referring again to FIG. 3, block 260, in order to insure accurate replay of the user session recorded and stored in the journal file, synchronization events are input into the journal file. The number and location of synchronization events input are dependent on the events and tasks performed during the recorded user session. The synchronization events are installed at those locations in the journal file after an event, representative of a user action, which must complete processing prior to the initiation of a subsequent event because the processing of the subsequent event is dependent on the process state of the completion of the prior event. The synchronization event indicates the event (or events) that is to be completed before any further events are initiated. The journaling mechanism, during replay, will halt further initiation of events until a signal is received by the journaling mechanism indicating that processing for the event identified in the synchronization event has completed execution. 
     Preferably, synchronization events are input at locations in the script between events which exchange state during processing. These synchronization events may be manually input by the user after the journal file is created or may be input by an automated process which reviews the events in the journal file and determines those events which require completed execution before initiating further actions. Preferably, the synchronization events are automatically input to the journal file according to the events representative of user actions captured. The toolkit, which interfaces the client processes to the window system, as well as the window server and window manager are modified to output a synchronization event that is captured by the synchronized journaling mechanism and placed in the journal file. The toolkit, window system, window server and window manager, are further modified to provide a signal to the synchronized journaling mechanism, during replay of the journal file, when it completes processing of events identified by the synchronization event such that the synchronized journaling mechanism knows when processing of events are complete and subsequent events can be initiated. 
     At block 270, FIG. 3, the events listed in the journal file are divided into sections. The sections are divided according to the synchronization points in the user session at which it is desirable to review the page tables in order to measure the working space and performance of the system. The sections may be created manually by the user after creation of the journal file or may be created by an automated process which creates the sections according to a predetermined criteria. Preferably, the synchronization points are located, and thus the sections are created, according to the performance measurements to be taken. For example, the sections may be created to divide each event into individual sections such that the effect each event has on the working space of the system can be measured. Alternatively, each section may contain the events performed relevant to a particular task, or those events which occur within a particular window. 
     At the event locations in the journal file indicative of the beginning of a section, the event is inserted which, when executed during replay, causes a command to be sent to the paging analysis tool to clear the back copies of the page tables in the memory management unit of the computer system (block 280, FIG. 3). 
     Similarly, at the locations in the journal file indicative of the end of a section, the event is inserted which, when executed during replay, causes a command to be sent to the paging analysis tool to read the back copies of the page tables in the memory management unit of the computer system and store them in a file (block 290, FIG. 3). 
     These events incorporate synchronization events, such that during replay, the journaling mechanism will not initiate further events from the journal file until a signal is received from the paging analysis tool indicating that execution of the commands initiated are complete. This insures that the measurements taken accurately reflect the measurements for the section and do not include paging information for a subsequent section. 
     Once these steps are performed, the journal file is complete and ready to be replayed to perform benchmarking measurements. An example of a script which is used to generate a journal file including synchronization events and actions to perform measurements of the working space generated for the script of FIG. 4 is illustrated by FIG. 5. An ASCII text version of the corresponding journal file is illustrated by FIG. 6. Referring to FIG. 6, the synchronization events are noted at those lines beginning with &#34;s&#34;. For example at line 410 a synchronization event is installed to synchronize with &#34;/GetKeyState&#34;. Thus during replay, the synchronized journaling mechanism will wait until the processing with respect to /GetKeyState is complete before continuing initiation of events starting with line 415. Similarly, the synchronization event at line 420 will cause the journaling mechanism to wait until the actions &#34;/SubUnviewableNotify /UnviewableNotify /UnmapNotify /DoItEvent /DoItEvent&#34; are complete before initiating the action at line 425. 
     The events to control the paging analysis tool are noted at those lines beginning with &#34;w&#34;. In the present illustration the command &#34;/F3-done&#34;, is the event which represents the dhat command to cause the paging analysis tool to clear the back copies of the page tables so that an accurate measurement of the working set for the section of the journal file can be achieved. The command at line 430 &#34;/F4 --  done&#34; is located after the last action to be taken and is the event which represents the &#34;snapshot&#34; command issued to the paging analysis tool to cause the back copies of the page tables to be read and stored in a file. 
     At block 300, FIG. 3, to benchmark the computer system, the journal file is replayed by the synchronized journaling mechanism. The events listed in the file are initiated in the sequence listed. When a synchronization event is reached, the synchronized journaling mechanism halts initiation of subsequent events until a signal is received indicating that process execution of the event identified by the synchronization event is complete. Furthermore, when an event to clear the back copies of the page tables is reached in the file, initiation of subsequent events in the file is halted, the command is sent to the paging analysis tool which clears the back copies of the page tables and sends back a signal to the synchronized journaling mechanism indicating that the execution of the command is complete. Similarly, when the event to read and copy the back events in the file is halted, the command is sent to the paging analysis tool which reads the page tables, copies them into a file and sends back a signal to the synchronized journaling mechanism indicating that the execution of the command is complete. 
     At the end of the replay process, at block 310, the file containing the copies or snapshots of the page tables are reviewed and analyzed to determine the working sets for the different sections of the user session. FIG. 7 is illustrative of page tables copied for a section in a file pursuant to commands issued by the synchronized journaling mechanism of the present invention. Page tables for four processes, textedit, mailtool, cmdtool and cmdtool, are respectively identified by process identification numbers 2244, 2246, 2238 and 2241. The character &#34;R&#34; indicates that a shared page has been referenced and the character &#34;X&#34; indicates that a private page has been referenced. The characters &#34;a&#34;, &#34;w&#34; and &#34;r&#34; identify unreferenced shared pages and &#34;x&#34; identifies unreferenced private pages. The page tables for each section are reviewed and a count of the number of shared and private pages referenced during a section is made. From this information, at block 320, the working set for each section can be determined. 
     It has been determined that for benchmarking a variety of systems, an accurate representation of the working set of a computer system can be defined to be the average of the working set of the application processes that are part of the benchmark. The average working set for the benchmark for a system consisting of shared and private pages is defined as: ws=[average shared pages]+(np)*[average private pages per process]; or ##EQU1## 
     Where np is the number of processes executing during the benchmark, ns is the number snapshot points, x i  the number of shared pages in snapshot i, y ij  =the number of private pages in snapshot i for a process j, and ws is the working set of a the benchmark in pages. Similarly, for a system consisting of only private pages the working set is for the benchmark is defined as: ##EQU2## Through the analysis of the working set of private and shared memory, including shared libraries, benchmarking of systems can be implemented across a variety of systems and architectures. 
     While the invention has been described in conjunction with the preferred embodiment, it is evident that numerous alternative, modifications, variations, and uses will be apparent to those skilled in the art in light of the foregoing description.