[icf-dev] Performance retrieving repository information

Posted by LegacyUser on 21-Aug-2002 09:37

Hello,

I did some performance comparision between Dynamics 1.1 and Dynamics 2

directly after migrating the same repository - so the amount of

information is the same. As we are developing an OpenClient (Visual

Basic) dynamic graphical frond end driven by the Dynamics repository it

is essentual for us to retrieve information from the repository as fast

as possible.

I used ry/app/rycsofetch.p in Dynamics 1.1 and fetchObject in

gshRepositoryManager in Dynamics 2 with the following code:

/* Code for Dynamics 1.1 */

DEFINE VARIABLE hHandleObjectCache AS HANDLE NO-UNDO.

DEFINE VARIABLE hTableObjectCache AS HANDLE NO-UNDO.

ETIME (YES) .

RUN ry\app\rycsofetch.p

("customerdw",

hHandleObjectCache,

TABLE-HANDLE hTableObjectCache,

OUTPUT TABLE tt_object_instance,

OUTPUT TABLE tt_page,

OUTPUT TABLE tt_page_instance,

OUTPUT TABLE tt_link,

OUTPUT TABLE ttAttributeValue,

OUTPUT TABLE ttUiEvent).

MESSAGE ETIME .

/* Code for Dynamics 2 */

DEFINE VARIABLE hBufferCacheBuffer AS HANDLE NO-UNDO.

DEFINE VARIABLE hClassAttributeTable AS HANDLE NO-UNDO EXTENT 26.

ETIME(YES) .

RUN fetchObject IN gshRepositoryManager ("customerdw", /* object name */

22042, /* user object for admin

user */

"", /* result code */

"", /* run attribute */

426, /* language english */

TRUE, /* entire container */

FALSE, /* design mode */

OUTPUT hBufferCacheBuffer,

OUTPUT TABLE CACHE_object,

OUTPUT TABLE CACHE_objectpage,

OUTPUT TABLE

CACHE_objectpageinstance,

OUTPUT TABLE CACHE_objectlink,

OUTPUT TABLE

CACHE_objectuievent,

OUTPUT TABLE-HANDLE

hClassAttributeTable[1],

OUTPUT TABLE-HANDLE

hClassAttributeTable[2],

OUTPUT TABLE-HANDLE

hClassAttributeTable[3],

OUTPUT TABLE-HANDLE

hClassAttributeTable[4],

OUTPUT TABLE-HANDLE

hClassAttributeTable[5],

OUTPUT TABLE-HANDLE

hClassAttributeTable[6],

OUTPUT TABLE-HANDLE

hClassAttributeTable[7],

OUTPUT TABLE-HANDLE

hClassAttributeTable[8],

OUTPUT TABLE-HANDLE

hClassAttributeTable[9],

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable,

OUTPUT TABLE-HANDLE

hClassAttributeTable

).

MESSAGE ETIME SKIP

VIEW-AS ALERT-BOX INFORMATION .

I ran both tests on the same machine (our development server in terminal

server mode, dual processor, up-to-date hardware). icfdb started with

the same parameters multi-user (-B 25000). Connection via self-service

client and ran the tests a couple of times the get good averages.

The container "customerdw" contains about 140 object instances

(toolbars, folder, sdos, viewer, browsers, fields in viewers etc.) and

should be considered as a small to medium sized object for out

application.

The test results confuse me very much.

Dynamics 1.1 is very constant in retrievig the values: 3.5 seconds

Dynamics 2 needs 7 to 8 seconds for the first fetch in a session and 3.5

to 4 seconds for the following fetches in the same session.

We were hoping to get much better performance with version 2 but in fact

we receive a 10%-100% worse performance when reading the repository. To

have pretty good results in total we would expect less than a single

second (as this information needs to be transported to the client and

rendered there) .

Has anybody else ran test like these with object definitions similar

complex as described here? Is my benchmark code wrong? What else should

I do to speed test the system and retrieve the information needed to

render the screens.

Regards,

Mike

To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org

For additional commands, e-mail: dev-help@icf.possenet.org

All Replies

This thread is closed