Skip to Content
author's profile photo Former Member
Former Member

KM. XMLForms. Performance.

Posted on Jun 30, 2004 at 06:18 AM 10 Views

Hi,

I first time faced with XMLForms of KM at a client project and the client experiences serious problems in terms of performance. I wonder whether somebody has successfully implemented a similar case or anybody may give practical suggestions/ideas/advice how to investigate the problem.

Here is the system:

EP60 SP2 Patch 3 Hotfix 7 and CM Patch 3 Hotfix 4. HPUX11, 750Mh, 3Gb memory, HP JDK1.3.1_13, Oracle 9i.

1. There is a DB based CM repository with AutoVersioning, Preserve Version Histories and Internal Links Default To Dynamic are all turned ON.

2. The repository has 15 services:

• accessstatistic

• comment

• discussion

• feedback

• layout

• personalnote

• properties

• rating

• statemngt

• subscription

• svc_acl

• Tbp

3. The repository has caches tuned according to the recommendation (from How to tune KM caches).

4. Filters. I don't know how to get a list of all fliters applied to the repository but I was browsing one by one filter and found that the following filters applied to the repository:

• Kmfaqs

• Kmnews

• Xmlforms_filter

Besides that there are other filters applied to the repository but they're not active.

5. I browsed the repository directrly and saw for some documents 100 root versions and inside other tens of subversions though the original documents/folders are not in such a huge range (I mean without their versioned clones).

That's the description. Now the problem. All documents are pretty small (3-10Kb). We have a load test and if for one user to get a page takes 5 seconds for "loadtest" with 25(!) users it takes 20-30 seconds. I don't see any custom developed code in the process of getting those pages involved and all known recommendation have already been applied. I thought about creating another repository withouth XSL transformation put there transformed pages (in HTML form already) and run the script again but what can it lead me to? That our KM's XSL transformation doesn't cope with 25 users? Hardly believable. I suspect as a candidate also XSLs themselves. Probably there is a way to optimize it if they're build by XML Form Builder but this idea also doen'st impress me much.

Does anybody have experience with such a problem?

Any ideas I may test or pointing to materials to learn are extremely wellcome. The matter is top urgent.

Many thanks in advance,

Roman

PORTAL Knowledge Management and Collaboration
Add comment
10|10000 characters needed characters exceeded

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Jun 30, 2004 at 12:06 PM

    Hi Roman,

    Are you creating new projects using the Forms Builder or are you checking the performance on the standard News and FAQ projects that already exist?

    Paul

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Karsten Hohage
      Jul 22, 2004 at 09:04 AM

      Hi all,

      I'm not ready to write an explanatory account on how we DID fix the problem yet but I'll write what we did together that led to better performance. When I originally wrote the question to the group performance of a load test was in average 20-30 seconds per transaction (transaction reading a document from the KM repository and rendering it with help of FlexUI). After performing following bellow steps it improved to 10-15 seconds (about 3 times faster!). So here are the changes we did:

      - patched OS (HP UX 11) with May 2004 bundle

      - kernel changes: ninode was highered from 16.384 to 32.768 (poss. Bottleneck as sar shows)

      - changed SGA for Oracle (doubled from +/- 2 GB to 4 GB)

      - logging of INFO messages was disabled

      - recreated indexes (SAP OSS 725057: /oracle/P04/SAP_OSS_725057.sql)

      - created a custom KM cache for the KM repository and a seperate cache for the KM repository small content (means created new caches that only that repository used solely)

      - increased number of open cursors per session (OPEN_CURSOR) from 50 to 100 (oracle only)

      The problem is we did all those steps at one blow so we don't know exactly what was the cause (or were the causes). It's been planed to perform the same steps one by one on a similar system and I thought we would have time to do it during passed two weeks but we still haven't found time. As soon as we find the cause I'll post additional report.

      Thanks all,

      Roman