Sponsor Link: EAS Training - Get training in the Essential toolset. Register your interest now. Read more
     
Home Documentation Administration Multi-User Installation - Performance Troubleshooting
Multi-User Installation - Performance Troubleshooting PDF Print E-mail

Most performance problems are related directly to the amount of memory that is required by the server. As the repository grows (e.g. > 1000 instances), more memory is required by the server, in particular if the Essential Viewer component running in Tomcat is co-located with the Essential Modeller running in the Protege Server.

 

Memory Requirements

As the repository grows in terms of the number of instances, in particular when you get beyond 1000-2000 instances, you should provide around 2GB memory on the physical server platform on which you are running Essential Architecture Manager server.

 

CPU Load

It is common for the Essential Viewer component - running in Tomcat - to be deployed alongside the Essential Modeller component - running in the Protege Server. Both require large amounts of memory, but the XSLT approach used by many of the analysis reports of Essential Viewer is also CPU intensive. If you are experiencing performance and response issues with the server, allocating an additional CPU (e.g. Dual CPU server) will enable the physical host server to manage the load of both of the Essential Architecture Manager server components.

Change History

Using the Collaborative Protege tab plugin is a good thing for team and multi-user repositories. A very detailed change log is kept in an OWL project that is associated with your active project - called the Annotations project. Currently (Protege 3.3.1), this is only stored using a file-based project - in 3 related files:

  • annotations_<project>.pprj
  • annotations_<project>.rdfs
  • annotations_<project>.rdf

There is no option to have this content - especially the *.rdf and *rdfs files stored in a relational database (possibly available in Protege 3.4). Having this detailed change history stored in files means that these files (the *.rdf file in particular) gets very large quite quickly. When it goes over 3.5MB it will start to affect the performance of the Protege server.

Solution

We have created a script to run in the Protege Script tab on the Annotations project file to perform housekeeping on this file as follows:

It turns out that the Protege team are on the same page with this and have announced an enhancement on the Changes tab as a menu option to clear the change history (with an option to archive it first). We are, therefore, in the absence of a database back-end for the Annotations project, comfortable that this is the best-practice way of managing the change history. 

Script

To use this script follow these simple steps

  • Stop the Protege server - Windows, Mac OS X, Linux, Unix.
  • Open the current annotations_<project>.pprj file in Protege as a native file-based project (not via a server)
  • If it's not already there, add the Protege Script tab (Project->Configure and select Protege Script Tab), if it is, go to the script tab
  • Run this script (below) using the command
  • execfile("<path to the script>/changeHistHousekeeping.py")
  • Save the project file
  • Close the project
  • Re-start the Protege server


The latest version of the script is provided here.

 

# (c)2008 EAS ltd.

# 19.02.2008    JWC v1.0

# 18.04.2008    JWC Updated to remove more instances and to force an archive, 1st

# Archive and purge changes [annotations] projects

#

# Run this against the annotations_<myProject>.pprj

# 1. Stop the server

# 2. Open the annotations file in stand-alone mode (just open the local PPRJ file)

# 3. Go to the Script tab and run this script

# 4. Remember to save the Annotations project on completion of this script

 

import java

# Do the archive

from edu.stanford.smi.protege.util import ArchiveManager

anArchiveMgr = ArchiveManager.getArchiveManager()

anArchiveMgr.archive(kb.getProject(), "Housekeeping archive of current change history")

 

print "Archive completed successfully"

# Remove the changes, etc from the current history
# Remove timestamps
rmInsts = kb.getCls("Timestamp").getDirectInstances()
print "Removing ", rmInsts.size(), " Timestamp instances"
for delInst in rmInsts: delInst.delete()
# Remove the changes
rmChanges = kb.getCls("Change").getInstances()
print "Removing ", rmChanges.size(), " Change instances (including all subclasses)"
for delInst in rmChanges: delInst.delete()
# Remove Ontology Components
rmOntComps = kb.getCls("Ontology_Component").getInstances()
print "Removing ", rmOntComps.size(), " Ontology Component instances (including all subclasses)"
for delInst in rmOntComps: delInst.delete()
# Remove Annotations
rmAnnotations = kb.getCls("Annotation").getInstances()
print "Removing ", rmAnnotations.size(), " Annotation instances (including all subclasses)"

for delInst in rmAnnotations: delInst.delete()

print "Finished."

 

 
Related Articles