Patent Application
20060282832
The subject matter described herein relates to the calculation of module runtimes on multiple platforms.
Applications are being increasingly run on several different software platforms. For example, a single application may include modules that are executed in JAVA, .NET, and the like on a front-end (e.g., graphical user interface) for user interaction, and modules that are executed in C/C++ or Advanced Business Application Programming (ABAP) and the like for back-end processing. In order to identify and characterize performance problems associated with the operation of the application, and additionally to monitor application load, the runtime of each of module must be determined.
As clocks typically differ for each of the platforms (or are not otherwise synchronized), the runtime of each of the modules cannot be determined by collecting time stamps for all of the modules. Alternatively, a software platform could be configured to transmit a signal identifying a particular module and indicating whether execution of such module has commenced or terminated. However, the amount of resources (e.g., bandwidth, processing, etc.) required to continually exchange performance metrics data between platforms makes such an approach unfeasible.
In one aspect, a method determine runtimes of a plurality of modules executed on each of at least two platforms (e.g., platforms with non-synchronized clocks). A start event is appended to a stack of events when each module on a first platform is executed. The start event may be used to identify the executed module. Each appended start event in the stack of events is closed when execution of the corresponding module is terminated. Runtimes for each of the modules are determined based on at least when the corresponding appended start event is closed. Data including the runtimes of each of the modules executed on the first platform is transmitted to a second platform when execution of modules ceases on the first platform.
In some variations, the method may automatically determine a runtime by determining, for a first module on the first platform, the difference between a first amount of elapsed time between an appending of the start event for the first module and a closing of the appended start event for the first module and runtimes for any other modules executed during the first amount of elapsed time. In such a variation, the method may further comprise determining, for a second module on the first platform, the difference between a second amount of elapsed time between an appending of the start event for the second module and a closing of the appended start event for the second module (that falls within the first amount of time) and runtimes for any other modules executed during the second amount of elapsed time other than the first module.
The method may include appending a start event to a stack of events when each module on a third platform is executed, closing each appended start event in the stack of events when execution of the corresponding module is terminated, automatically determining a runtime for each of the modules when the appended start event is closed, and transmitting data to the second platform including the runtimes of each of the modules executed on the third platform when execution of modules ceases on the third platform. Additionally or in the alternative, the method may further comprise executing a plurality of modules on the second platform, automatically determining runtimes for each of the modules executed on the second platform, executing an additional plurality of modules on the first platform, automatically determining runtimes for each of the additional modules executed on the first platform, and transmitting data to the second platform including the runtimes of each of the additional modules executed on the second platform when execution of the additional modules on the first platform terminates. With the latter variation, the method may also comprise storing the runtimes of each of the modules executed on the first and second platforms.
In yet other variations, the method may further comprise accumulating all times that are not assigned to a module between a first appended start event and when execution of modules on the first platform ceases. These accumulated times may be transmitted to the second platform when execution of modules ceases on the first platform.
The method may operate in connection with an application that executes at least one module on each of a plurality of platforms in sequence (e.g., three modules are executed on a first platform, followed by five modules being executed on a second platform, followed by two modules being executed on a third platform, followed by six modules being executed on the second platform, etc.). The application may pertain to a variety of tasks including a query of a data warehouse.
In another aspect, an apparatus to determine runtimes of a plurality of modules executed on at least two platforms may comprise a monitoring unit, a calculation unit, and a transmitter. The monitoring unit may be operable to append a start event to a stack of events when each module on a first platform is executed. Such a start event may identify the executed module. The monitoring unit may also close each appended start event in the stack of events when execution of the corresponding module is terminated. The calculation unit is operable to determine a runtime for each of the modules based on at least when the corresponding appended start event is closed. The transmitter is operable to transmit data to a second platform including the runtimes of each of the modules executed on the first platform when execution of modules ceases on the first platform. Optionally, the apparatus may be coupled to a data repository to store data pertaining to the runtimes of the measured modules.
In yet another aspect, an interrelated method for determining runtimes of a plurality of modules executed on each of a plurality of platforms (with one of the platforms being designated a master platform) may comprise calculating, for each platform, runtimes for each of a series of executed modules, and transmitting data including the calculated runtimes to the master platform when execution of modules ceases on each platform other than the master platform.
In still another aspect, a further interrelated method for determining runtimes of at least one module executed on at least one platform may comprise executing at least one module on a first platform, calculating, for at least one executed module, a runtime based on a difference between (i) an amount of time equal elapsed from a start and a stop of the execution of the module and (ii) aggregate runtimes for any intervening nested modules executed during the execution of the module, and transmitting data to a second platform including the calculated runtimes when execution of the at least one module ceases on the first platform.
A further interrelated method may comprise determining if a call by an application to a first platform supports transportation of statistic information regarding runtimes of executed modules and elapsed times of modules that are currently being executed on a second platform to the first platform, transporting the statistics information using a program running in connection with the first call, or initiating a second call to the first platform that supports transport of statistics information and transporting the statistics information using a program running in connection with the second call.
Computer program products, which may be embodied on computer readable-material, are also described. Such computer program products may include executable instructions that cause a computer system to conduct one or more of the method acts described herein.
Similarly, computer systems are also described that may include a processor and a memory coupled to the processor. The memory may encode one or more programs that cause the processor to perform one or more of the method acts described herein.
The subject matter described herein provides many advantages. For example, more accurate estimates of resource consumption and runtimes associated with modules executed on each of several platforms may be provided. Such information may be used to monitor load on systems and to detect sources of increased query runtime (e.g., front-end problems, database access, slow communications, etc.) including individual runtimes for measured modules.
The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from the description and drawings, and from the claims.
Like reference symbols in the various drawings indicate like elements.
The following provides useful information for understanding and implementing the subject matter described herein as well as optional variations that may be implemented singly or in combination depending on the desired configuration.
The application may comprise, for example, a business intelligence query of a data repository. Such a query might include reading transaction data from a data repository, processing and analyzing the data in an online analytical processing (OLAP) engine, reading the master, checking any authorizations pertaining to the data, and passing the results to a front end platform that renders web items or formats cells (depending on the desired display format). As each of these tasks may includes modules executed on a differing platforms (e.g., JAVA and .NET for front-end components and C/C++ and advanced business application programming (ABAP) for back-end components), the runtimes for the modules on the differing platforms may be determined separately.
The downward pointing arrows designate the initiation of execution of each of the modules A, B, C, D, E and the upward pointing arrows designate the termination of the execution of each of the modules A, B, C, D, E. The amount of time in between the downward pointing arrow and the upward pointing arrow for a particular module is used to determine the runtime. In some cases, modules being executed include further nested modules being executed. For example, between a start event 305 and an end event 375 of module A, there is a start event 315 and an end event 325 for nested module B, a start event 335 and an end event 365 for nested module C. Moreover, during execution of module C, there is a start event 345 and an end event 355 for nested module D. In order to determine the runtime of module A, the runtimes of each of modules B, C, and D must be determined and subtracted from an amount of time between the start event 305 and the end event 375 for module A.
At the start of each modules that is measured for runtime statistics, a start event 305, 315, 335, 345, 385 may be sent. These start events 305, 315, 335, 345, 385 are appended to a stack of events with a unique identifier with the status “open”. Stages of the stack of events (call stack) 310, 320, 340, 350, 390 respectively correspond to the start events 305, 315, 335, 345, 385.
When the start event 305 for module A is appended to the stack of events 310, module A is assigned ‘1’ as a unique designator, ‘X’ indicating that the module A is open, and optionally a StackID ‘2’ which is used for indicating relative placement within the stack of events. When execution of module B is initiated, start event 315 is appended to the stack of events and module B is assigned ‘2’ as a unique designator, an ‘X’ and optionally StackID ‘3’. When execution of module B ends or is otherwise terminated, an end event 325 causes the start event 315 to be deleted from the stack of events 330. Start event 335 corresponding to module C is appended to the stack of events 340 and is assigned module ‘3’ as a unique identifier, ‘X’ indicating that the module B is open, and optionally a StackID ‘4’.
Subsequently, start event 345 corresponding to module d is appended to the stack of events 350 and is assigned module ‘4’ as a unique identifier, ‘X’ indicating that the module B is open, and optionally a StackID ‘5’. When execution of module D ends or is otherwise terminated, an end event 355 causes the start event 345 to be deleted from the stack of events 360. In addition, when execution of module C ends or is otherwise terminated, an end event 365 causes the start event 335 to be deleted from the stack of events 370.
Further, when execution of module A ends or is otherwise terminated, an end event 375 causes the start event 305 to be deleted from the stack of events 380. Optionally, additional modules, such as module E may be executed causing start event 385 to be appended to stack of events 390 so that module E is assigned ‘5’ as a unique designator, ‘X’ indicating that the module A is open, and optionally a StackID ‘6’. Thereafter, the execution of further modules may be executed and ended until the application begins executing modules on a next platform within a sequence of platforms.
Each change in the stack of events 310, 320, 330, 340, 350, 360, 370, 380, 390 may be used to determine the runtime of each module A, B, C, D, E. If a second module is initiated with a start event before a subsequently initiated start event of a first module is closed, the time elapsed between the two start events is added to the first module (e.g., module D is executed during module C). If the second module is closed with an end event, the time between the start and end events for the second module are added to the second module and the event is deleted from the stack of events so the only open module is the first module. Such an arrangement ensures that there is no span of time which is used to calculate runtimes of more than one module.
In some variations, the first start event 305 may trigger a special event “not assigned times”. This special event is always open and may be assigned ‘0’ as a unique designator, ‘X’ indicating that the module A is open, and optionally a StackID ‘1’ in each stage of the stack of events for a certain platform. Therefore, the “not assigned times” special event may be used to verify that the individual runtimes of each of the executed modules A, B, C, D, E do not exceed the total runtime on a particular platform. Moreover, if the “not assigned times” special event exceeds a certain threshold, then an indication may be provided to a systems administrator that refinements may be needed to the statistics recording process.
With reference to
Once control is transferred, a start time is calculated on the master platform 420 (e.g., start time=current time−Σti). The master platform 420 then stores the module runtimes passed en masse in a data repository or memory storage device and executes modules and subsequently passes control back to the non-master platform 410. The non-master platform 410 executes a second series of modules, records the runtimes of each of these modules (e.g., record (t1A(Mod. 1) . . . tnB(Mod. N)) and, at step 460, passes on data indicating the runtimes of each these modules to the master platform 460. The master platform then stores these recorded times (for example, in a coupled data repository or a memory device), and optionally, compensates for any variations due to time required to communicate the data from the non-master platform 410 to the master platform 420 (e.g., network time=Δ(current time−Σti)−last measured time). Control of the process is then returned, at step 470, to the non-master platform.
Although only two platforms are illustrated, it will be appreciated that multiple platforms may be utilized with one of the platforms being designated a master platform. With such an arrangement, each non-master platform would provide data indicating the module runtimes to the master platform each time control of the process is switched to another platform. Moreover, it will be appreciated that platforms may execute modules in parallel so that each platform transmits data to the master platform after ceasing to execute modules (and/or control of the process passes to another platform).
At step 510, an application initiates a first call to a master platform. The call may be part of an overall process being performed by the application (e.g., change of platform as part of a query of a database) or it may be a call related substantially to the reporting of the performance statistics of a secondary platform. The application, at step 520, obtains the runtimes for executed modules and elapsed times for modules that are still being executed from a statistic manager associated with the secondary platform. Subsequently, it is determined, at step 530, whether the first call supports the transport of statistics information. If that is the case, at step 540, the statistic information is transported using a program running in connection with the first call. Otherwise, at step 550, a separate call (e.g., second call) is initiated that transports the statistic information to the master platform prior to the first call. If the application that is running is controlled by the secondary platform, the application framework submits any statistics information not previously communicated to the master system after completion of a user interaction step.
With the process 500 of
Various implementations of the subject matter described herein may be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations may include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.
To provide for interaction with a user, the subject matter described herein may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.
The subject matter described herein may be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a client computer having a graphical user interface or a Web browser through which a user may interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.
The computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
Although a few variations have been described in detail above, other modifications are possible. For example, the logic flow depicted in the accompanying figures and described herein do not require the particular order shown, or sequential order, to achieve desirable results. Other embodiments may be within the scope of the following claims.
