Re: Performance problems opening ontology in multi-user mode with ChAO

Hi Ulf,

The times you are reporting are indeed bad, because your ChAO is still 
fairly small. We use ChAO in production since 2009 and keep all the 
changes. We have over 10 millions rows in the ChAO db. The problem in 
your case is the Changes tab (see below).

What happens is that some things in ChAO get cached at the 
initialization of a client (e.g. sorted changes if you have ChangesTab 
activated, and annotation counts), and these are the operations that 
take such a long time.

Here are some things that we do occasionally:

1. Delete all subchanges (they increase the size of ChAO 3 to 10 times, 
depending on the type of changes you are making). You would still have 
the top level changes that make sense to the user. We do this when we 
have new releases of the software, or when we need to take the server 
down, because it is done with a mysql script and he server should not be 
running. The script is in our SVN, in case you would like to try it:
http://smi-protege.stanford.edu/svn/change-management/trunk/etc/delete_all_subchanges_with_inner_joins_v2.sql?view=markup

This script will create a new table (new_youroldtablename) that has all 
the subchanges removed. Usually, I drop the old ChAO table, and rename 
the new one with the old name. The indexes are however not renamed, so I 
use this script to rename the indexes:
http://smi-protege.stanford.edu/svn/change-management/trunk/etc/fix_indexes_icat.txt?view=markup

(you would need to change the names in this script to match your 
configuration)

2. If you have a large number of annotations, you can disable the 
precaching of annotation counts (the annotation count is shown in the 
class tree). You can add a line in your client protege.properties:

collab.precache.notes.count=false

What version of Protege are you using? How large is your ontology?

In any case, a quick fix would be to disable the ChangesTab in the 
configuration of the clients. Then the GetSortedTopLevelChangesJob would 
not be called. You would still see the list of changes of the selected 
class in the collaboration panel in the Changes tab. If you need to make 
searches in the changes history, I suggest using the Search tab in the 
collaboration panel.

Let me know how it goes!

Tania



On 10/04/2012 08:42 AM, Ulf Licht wrote:
> Hello list,
>
> we recently started to use the Change and Annotation Ontology (ChAO) with
> our Protege multi-user installation. It worked fine for a while but now we
> see serious performance degradation. The ChAO is persisted in an Oracle
> database and the table current contains about 195.000 entries after using
> it for a few weeks. Currently opening a project with an attached ChAO is
> impacted the most (up to 70 minutes). The client log file indicates that
> opening the ChAO for the project takes the longest time. We did some
> further analysis and found that a server job called
> "GetSortedTopLevelChangesJob", which is started by the Changes Tab of an
> Protege client, issues many individual prepared database statements, which
> take a lot of time to complete. We created additional indexes to mitigate
> the problem and brought the time for opening a project to about 20
> minutes, which is still not acceptable.
>
> Did anyone experience similar performance problems while using the ChAO
> and has any idea how to improve it? Archiving the ChAO every few weeks is
> not an option since we would have to search for changes over many archived
> ChAOs. An archive interval of once a year would be acceptable. How do
> others handle archiving of ChAO information?
>
> Best regards,
> Ulf
>
>
>
> Esprit Europe GmbH
> Esprit-Allee
> 40882 Ratingen
>
> P.O. Box:
> Esprit Europe GmbH
> 40842 Ratingen
>
> t +49 2102 123-0
> f +49 2102 123-45100
> i www.esprit.com
>
> Amtsgericht Düsseldorf,
> HRB 28967, VAT-ID: DE 162905814
> Geschäftsführer: W.T.C. van der Vis, Ernst-Peter Vogel, Jürgen Haas,
> Julia Merkel
>
> Confidential Notice: The information in this document is confidential. It is intended only for the use of the named recipient. Internet communications are not secure and therefore our Company does not accept legal responsibility for the contents of this message. If you are not the intended recipient  please notify us immediately and then delete this document.
>
> Please consider your environmental responsibility before printing this e-mail
> _______________________________________________
> protege-discussion mailing list
> [email protected]
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03

_______________________________________________
protege-discussion mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/protege-discussion

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03