Search Mailing List Archives
[protege-discussion] Performance problems opening ontology in multi-user mode with ChAO
Ulf.Licht at esprit.com
Thu Oct 11 01:03:46 PDT 2012
the workaround to disable the Changes Tab, which needs to be done in the
project on the server in order to persist for the clients, does make
startup instantaneous. Seeing the changes for the selected instance in the
collaboration panel is usually enough. Thank you for the advice!
What is the Changes Tab needed for? How long does it take to open the
Changes Tab with your ChAO containing 10 million rows ???
We did use the script to delete the subchanges but the number of rows in
the ChAO table was only reduced from 195.000 to 165.000. In our case the
factor 3-10 does not seem to hold true but we will continue to run the
script from time to time.
We do not have a large number of annotations therefore disabling the
precaching of annotation counts does not help us.
Our Protege version is 3.4.8 on client and server side. Our ontology (not
ChAO) contains 15.528 frames, 14397 instances, 10 facets, 712 slots and
409 classes according to Project-->Metrics.
Von: Tania Tudorache <tudorache at stanford.edu>
An: User support for Core Protege and the Protege-Frames editor
<protege-discussion at lists.stanford.edu>,
Datum: 04.10.2012 19:40
Betreff: Re: [protege-discussion] Performance problems opening
ontology in multi-user mode with ChAO
Gesendet von: protege-discussion-bounces at lists.stanford.edu
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
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:
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:
(you would need to change the names in this script to match your
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:
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
Let me know how it goes!
On 10/04/2012 08:42 AM, Ulf Licht wrote:
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?
Esprit Europe GmbH
Esprit Europe GmbH
t +49 2102 123-0
f +49 2102 123-45100
HRB 28967, VAT-ID: DE 162905814
Geschäftsführer: W.T.C. van der Vis, Ernst-Peter Vogel, Jürgen Haas,
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
More information about the protege-discussion