Thanks for the reply.
I have not added any instances yet. Just using the base essential metamodel now. I renamed the baseline metamodel and hosted it in the SQL server.
EA Project taking long time to open
-
manikvijay
- Posts: 20
- Joined: 04 Apr 2011, 18:19
You do not have the required permissions to view the files attached to this post.
-
manikvijay
- Posts: 20
- Joined: 04 Apr 2011, 18:19
Hi Jonathan,
Sorry for all along. I just got in to your words of saying instances, the baseline model from essential has 25000 instances. And i tried to host the whole project that was pretty heavy that i missed your words before (sorry for that). so now i created a brand new project with only one instance then the client loads like a champ. Thanks for your help.
However, the problem of latency prevails as we grow our metamodel in the future.
I really appreciate your help all along.
Thanks
-Mani
Sorry for all along. I just got in to your words of saying instances, the baseline model from essential has 25000 instances. And i tried to host the whole project that was pretty heavy that i missed your words before (sorry for that). so now i created a brand new project with only one instance then the client loads like a champ. Thanks for your help.
However, the problem of latency prevails as we grow our metamodel in the future.
I really appreciate your help all along.
Thanks
-Mani
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Mani,
Thanks for getting back to me. 25,000 should be no problem. The Protege team have tested to over 100,000 instances with no issues.
There are some tuning parameters to look at to improve things, though. Firstly, if you are persisting your repository in the PPRJ/PINS/PONT files approach, then the entire repository is loaded into memory, which can take some time if you've got a lot of instances. You'll notice this even more in multi-user mode if the server is running and using a file 'backend'.
Using a database backend really improves things because Protege takes a more efficient approach to loading and caching instances. We recommend that you use a database backend for the server (if you haven't already) in multi-user mode.
In multi-user mode, there are some parameters that you can set on the clients to affect their approach to caching. The later versions (3.4.x) include compression of the 'conversation' between the client and server which I think is activated by default. Worth checking that, too.
Hope this helps
Jonathan
Thanks for getting back to me. 25,000 should be no problem. The Protege team have tested to over 100,000 instances with no issues.
There are some tuning parameters to look at to improve things, though. Firstly, if you are persisting your repository in the PPRJ/PINS/PONT files approach, then the entire repository is loaded into memory, which can take some time if you've got a lot of instances. You'll notice this even more in multi-user mode if the server is running and using a file 'backend'.
Using a database backend really improves things because Protege takes a more efficient approach to loading and caching instances. We recommend that you use a database backend for the server (if you haven't already) in multi-user mode.
In multi-user mode, there are some parameters that you can set on the clients to affect their approach to caching. The later versions (3.4.x) include compression of the 'conversation' between the client and server which I think is activated by default. Worth checking that, too.
Hope this helps
Jonathan
Essential Project Team
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Mani,
I've had a look at the Protege project files that you upload (thanks for that) and this has helped suggest some other things that need looking at.
Firstly, although it might sound like a good idea, I don't think it's necessary to switch on Track Changes or the Collaboration panel for the metaproject. Just to re-iterate, the purpose of this ontology is to manage the configuration of the server and that is all. I would suggest that you do not want to have collaborative, concurrent editing of this ontology, rather that you should be restricting access to it and only make edits to it when the server is stopped.
That is, to make a change:
By the way, the Protege team have been in recent versions making it possible to perform things like adding users and so on while the server is still running but this is done via the server administration option when you connect to the Protege server, not by directly editing the metaproject. I'm not sure of how 'in production' these capabilities are and in which version of Protege that they work. Worth checking their site.
So, when I opened your metaproject, I was immediately prompted to create the ChAO (changes ontology) for the metaproject. This is because 'Track Changes' is switched on in the Project options. Turn this off and close the Collaboration Panel and this should clear the need for the ChAO - and I now think that it is THIS changes repository that the server was complaining about not being able to find (as there wasn't one for your metaproject).
As I say, I think the best way forward is to turn off track changes and collaboration for the metaproject ontology.
The definition of the Essential AM Project in the metaproject looked fine and I notice that you have removed the Annotations project specification for this project (as we discussed in earlier posts).
However, I did notice that in the definition of the Annotations Essential AM Project that you had specified a .pprj file that was also included in the pack you posted. You had specified to store this ChAO project in the server area (which isn't necessarily a problem) but I thought is was worth pointing out that the changes / annotations repository (ChAO) is specific to each Protege project. That is, Essential AM Project would have it's own one - you do not share the ChAO across multiple repositories as they are created from within the selected Protege project by switching on Track Changes or the Collaborations Panel.
So, in the metaproject, we are telling the server where to find the project files that are already available. It will not create the ChAO for a project, you have to have created that already from within the selected project and then tell the metaproject where that ChAO (file, database etc.) can be found.
I would recommend that rather than manage all the ChAO annotations projects together, e.g. next to the metaproject, you keep the annotations project in the same folder as the Essential repository project. So, if you decide to enable change tracking / collaboration, open your Essential repository, switch these options on and Protege will prompt you to specify where and how to store the ChAO. Once you've done that and Protege has created the annotations project, then you can go back to the metaproject (having stopped the server first) and update the path to the annotations project for the Annotations Essential AM project to point to where you saved the ChAO.
I appreciate that this is a bit fiddly to set up but I think that it all makes sense once you understand how Protege works with this. Hope this post helps and as I say, I think that if we can straighten out your metaproject, you will improve the connection time as I think at the moment, the server is trying to connect to the Annotations project but there is only a PPRJ file (project definition) for that and no content for it, e.g. RDF files etc - as far as I can tell, this has been configured to use the 'changes.rdf' format (rather than a database). So the server is getting stuck unable to successfully open a partially configured project or something.
Jonathan
I've had a look at the Protege project files that you upload (thanks for that) and this has helped suggest some other things that need looking at.
Firstly, although it might sound like a good idea, I don't think it's necessary to switch on Track Changes or the Collaboration panel for the metaproject. Just to re-iterate, the purpose of this ontology is to manage the configuration of the server and that is all. I would suggest that you do not want to have collaborative, concurrent editing of this ontology, rather that you should be restricting access to it and only make edits to it when the server is stopped.
That is, to make a change:
- Stop the Protege Server
- Start a Protege client in stand-alone mode and directly open the metaproject.pprj file (you can do this from the server desktop or if the filesystem is shared, you could do this remotely).
- Make your changes and save the metaproject
- Close Protege client
- Restart the Protege Server
By the way, the Protege team have been in recent versions making it possible to perform things like adding users and so on while the server is still running but this is done via the server administration option when you connect to the Protege server, not by directly editing the metaproject. I'm not sure of how 'in production' these capabilities are and in which version of Protege that they work. Worth checking their site.
So, when I opened your metaproject, I was immediately prompted to create the ChAO (changes ontology) for the metaproject. This is because 'Track Changes' is switched on in the Project options. Turn this off and close the Collaboration Panel and this should clear the need for the ChAO - and I now think that it is THIS changes repository that the server was complaining about not being able to find (as there wasn't one for your metaproject).
As I say, I think the best way forward is to turn off track changes and collaboration for the metaproject ontology.
The definition of the Essential AM Project in the metaproject looked fine and I notice that you have removed the Annotations project specification for this project (as we discussed in earlier posts).
However, I did notice that in the definition of the Annotations Essential AM Project that you had specified a .pprj file that was also included in the pack you posted. You had specified to store this ChAO project in the server area (which isn't necessarily a problem) but I thought is was worth pointing out that the changes / annotations repository (ChAO) is specific to each Protege project. That is, Essential AM Project would have it's own one - you do not share the ChAO across multiple repositories as they are created from within the selected Protege project by switching on Track Changes or the Collaborations Panel.
So, in the metaproject, we are telling the server where to find the project files that are already available. It will not create the ChAO for a project, you have to have created that already from within the selected project and then tell the metaproject where that ChAO (file, database etc.) can be found.
I would recommend that rather than manage all the ChAO annotations projects together, e.g. next to the metaproject, you keep the annotations project in the same folder as the Essential repository project. So, if you decide to enable change tracking / collaboration, open your Essential repository, switch these options on and Protege will prompt you to specify where and how to store the ChAO. Once you've done that and Protege has created the annotations project, then you can go back to the metaproject (having stopped the server first) and update the path to the annotations project for the Annotations Essential AM project to point to where you saved the ChAO.
I appreciate that this is a bit fiddly to set up but I think that it all makes sense once you understand how Protege works with this. Hope this post helps and as I say, I think that if we can straighten out your metaproject, you will improve the connection time as I think at the moment, the server is trying to connect to the Annotations project but there is only a PPRJ file (project definition) for that and no content for it, e.g. RDF files etc - as far as I can tell, this has been configured to use the 'changes.rdf' format (rather than a database). So the server is getting stuck unable to successfully open a partially configured project or something.
Jonathan
Essential Project Team
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
A quick update on this thread.
We've established that there is an issue with Protege 3.4.6 that is causing the long time (over 1 minute 30 seconds) to initially open the Essential repository when working in multi-user mode.
This is being investigated and in the meantime, we recommend that all multi-user installations use version 3.4.4 of Protege.
Jonathan
We've established that there is an issue with Protege 3.4.6 that is causing the long time (over 1 minute 30 seconds) to initially open the Essential repository when working in multi-user mode.
This is being investigated and in the meantime, we recommend that all multi-user installations use version 3.4.4 of Protege.
Jonathan
Essential Project Team
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Just a quick update on this one.
Recently, the Protege team released version 3.4.8 and we can confirm that this issue has been resolved in this latest (at the time of writing) version.
Jonathan
Recently, the Protege team released version 3.4.8 and we can confirm that this issue has been resolved in this latest (at the time of writing) version.
Jonathan
Essential Project Team
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 15 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?
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?
I did get a reply with a possible workaround on the Protege-Discussion Mailing list:
https://mailman.stanford.edu/pipermail/ ... 06224.html
Best regards,
Ulf
https://mailman.stanford.edu/pipermail/ ... 06224.html
Best regards,
Ulf
