Browse Prior Art Database

Real-time analysis optimisation using grouped results in a system management environment

IP.com Disclosure Number: IPCOM000200120D
Publication Date: 2010-Sep-29
Document File: 2 page(s) / 77K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method for reducing the number of required requests to retrieve specific resource data. This technique is most useful where several custom-built requests have already been specified on the requesting client.

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

Page 01 of 2

Real-time analysis optimisation using grouped results in a system management environment

This disclosures discusses a method for reducing the number of requests required to a server application for specific resource data. It does this by analysing the queries being made by the client and looking for reducible patterns. That is any queries that can be reduced to a superset containing as many other queries as possible. The benefit of this is reduced resource usage on the server.

Request format
As an example here the following request format is used:
Resource type - The type of resource being requested
Key - The key field of the resource being requested. This could be specified as a generic value. Such as ABC*, meaning all resources with a key field starting with the characters ABC.

Query filter - A simple query format, specified as

=

, where

could be specified as a generic value. Such as FIELD=VAL*, meaning all resources with the field FIELD starting with the characters VAL.

An example of the request specified in a comma separated values (CSV) format: PROGRAM,ABC*,USECOUNT=5
Meaning request all PROGRAM resources with a key field of ABC* and a USECOUNT of 5.

Example requests
The following queries are to be made by the client to server (the ID field below is only specified here for reference):

ID

RESOURCE TYPE

KEY FILTER

QUERY FILTER

 1 FILE ABCDEFG* AAA=AAA*
2 FILE ABC* BBB=BBB
3 FILE ABCDE* CCC=CCC
4 FILE VWXYZ* DDD=DDD
5 FILE VW* DDD=DEF*
6 PROGRAM VW* DDD=DDD
Without this system, all 6 requests would be made by the client to the server. By applying this solution to the client requests, these can be reduce to just 3 actual requests as shown below. Let's look at how this is calculated.
1) Query ID=1 is created. No other query exist for FILE yet. So request ID=1 is created.
2) Query ID=2 is created. Resource type is FILE and Key filter is ABC*, which is a superset of ABCDEFG*. So request ID=1 is updated with the new Key filter of ABC*. The query fields are incompatible as they specify different fields, so the query filter is removed from the request ID=1.
3) Query ID=3 is created. Resource type is FILE and Key filter is ABCDE*, which is a subset of ABC*. So request ID=1 is left as it is. It still covers all 3 FILE resource queries.
4) Query ID=4 is created. Resource type is FILE and Key filter is VWXYZ*, which is unrelated to the key filter in request ID=1 so a new request ID=2 is created.
5) Query ID=5 is created. Resource type is FILE and Key filter is VW*, which

1


Page 02 of 2

is a superset of VWXYZ* (request ID=2). So request ID=2 is updated with the new Key filt...