Browse Prior Art Database

Method of Discovering Redundant Time-consuming Service Invocation in Software System

IP.com Disclosure Number: IPCOM000229559D
Publication Date: 2013-Aug-06

Publishing Venue

The IP.com Prior Art Database

Abstract

This disclosed method proposes one new way to point out where the redundant service invocation may locate in the software system. The main idea here is to leverage code instrumentation to inspect the program runtime data, in order to record all the service invocations data which contains the request and response data, and the stack data where the service invocation take places. And make analysis on these data to find out those service invocations with the same inputs and output. By pointing out where the redundant invocation codes locate, it offers solid basis on that to direct development team to those places to do code analysis to decide if eliminating these redundancies.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 24% of the total text.

Page 01 of 12

Method of Discovering Redundant Time

Method of Discovering Redundant Time-

Enterprise software system usually depends on the external or internal service, such as the web services invocation, database service invocation, etc. With the scale of software system getting bigger than ever before, it is very likely that there are many redundant time-consuming service invocations which return exactly the same data even within the same code execution logic. Also if there are many developers involved in the development process, or the system has been maintained many years, the possibility of redundant service invocations continually increases.

In many cases, the system sends out the same http requests with the same headers and url parameters or the same DB queries in one procedure, which is very likely to return the same response. For instance, the software system repeatedly invokes the same external service to retrieve the relatively stable service metadata, or in cloud computing area, the cloud consumer application repeatedly invoke the cloud service to retrieve the unchanged image metadata. As we all know, any REST request will communicate with another system through network, so that the operation is very time-consuming. Also the DB queries are always the time-consuming operations in any software system. Therefore, these repeat service invocations are very time-consuming and lead to the heavy overheads, which will become the performance bottleneck of the software system.

Additionally, such kind of redundant invoke is hard to discover with the static code inspection or analysis since the service request and response data are always dynamic. Furthermore, static code analysis is time-consuming and more important may not discover the accurate codes where redundant service invoke take place.

Let's image the following scenario, see FIG.1,

--consuming Service Invocation in Software System

consuming Service Invocation in Software System

1


Page 02 of 12

FIG.1

The system runs in a thread named Thread A which indicated by the bold horizontal line from left to right. The thread runs to through f1, f2 and then f3. In function f3, it sends out a REST request (Request 1) to external service, returning Response 1. Similarly, in f6 Request 2 is sent out, and Response 2 is returned. Again, in f13, the system sends Request 3 and the result is Response 3.

Suppose, in a run of Thread A, the three service requests have the same request data and the three responses also have the same response data. Such kind of case is somewhat usually happen in large software system. For instance, in the first run of Thread A, it processes the customer's request for deployment using image A and all of the three requests do the same thing to retrieve the metadata of image A, apparently they will initial the same requests data and get the same response data. Likewise, in the second run of Thread A, all of the three requests do the same thing to retrieve the metadata of image...