Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] RMI server scalability for Protege Frames 3.5 editor

John Pierre johnmapierre at gmail.com
Sun Jun 23 14:57:04 PDT 2013


Thanks for the thoughtful reply.  I am using Protege 3.5 Build 663.   The
.pprj file is only about 52K with about 150 or so class definitions for top
level classes, slots, layout properties, etc.

Looking at the fine grained logging on the server and the client it seems
it is loading 80MB of data when the client opens the ontology.  Seems to be
loading all the frames into the cache with 47,952 calls like this:

2013.06.22 12:21:57.975 PDT FINE: Invocation took 3 ms --
RemoteClientFrameStore$2.invoke()
2013.06.22 12:21:57.975 PDT FINE: Cache miss for frame named 1125R [171078]
-- RemoteClientFrameStore.ge
tFrame()
2013.06.22 12:21:57.975 PDT FINE: Remote invoke: getFrame Args: --
RemoteClientFrameStore$2.invoke()

I noticed that -Dserver.client.preload.skip and -Dpreload.frame.limit
properties do not seem to have any affect whatsoever.

I'll send some additional info off-line.  Sincere thanks!








On Sat, Jun 22, 2013 at 12:49 PM, Timothy Redmond <tredmond at stanford.edu>wrote:

>
> This type of performance problem is a tricky area and to understand it
> better we would have to understand exactly where the bottleneck is.  But my
> first questions would be how large is the pprj file and what version of
> Protege are you using.  We made a change to Protege recently that optimizes
> how the .pprj part of a frames project is loaded by the client.  Using the
> very latest version of Protege may dramatically improve the startup
> performance if the pprj file is large.
>
> If moving to the latest Protege is not sufficient then you could send me a
> copy of the ontology so that I could see the performance issue and find the
> bottleneck here.  If you send the ontology out of line I can keep it
> private if needed.
>
>
>
>  Therefore the culprit seems to be network demands of the rmi server.
>
>
> This sounds like a simple
>
>
>
> 1. What is the practical scalability limit of the Protege RMI
> client-server in terms of ontology size?
>
>
> The server-client is used with ontologies of over 128K classes.  In this
> example the ontology is also a mysql database project.  So the 25000 frames
> you describe is not that large.
>
>
>
>  2.  Are there additional configuration settings that we can try to get
> our ontology to load?
>
>
> It has been a long time since I worked on the protege 3 client server but
> I think you have found the main options.  But you should also be warned
> that
>
>             -Dserver.client.preload.skip=true
>
>
> might work against you.  You save time on the preload but all the
> operations thereafter are slower until the client side cache has been
> sufficiently built up.
>
>
>
>  3.  Are there other collaboration models we could try for allowing
> multiple people to work on a large scale Frames ontology besides the rmi
> client-server approach?
>
>
> You could also try webprotege.
>
> -Timothy
>
>
>
>
> On 06/19/2013 10:26 AM, John Pierre wrote:
>
>   We are trying to set up a collaborative installation so multiple
> developers can edit a Frames ontology.  The ontology currently has about
> 25,000 frames.
>
>  We have successfully configured the RMI server and can connect clients to
> the server and access the example ontologies across the network.
>
>  The problem is that our 25,000 frame ontology isn't able to load into the
> clients when accessed across the network.
>
>  Our ontology is MySQL backed.
>
>  The ontology loads fine when accessed on the same machine without going
> through the rmi server.
>
>  The ontology loads but takes several minutes to do so when running the
> client and server on the same machine through the localhost loopback.
>
>  The ontology loading hangs and cannot load when running the client and
> server on different machines either on a wide area network (20+Mbps) nor on
> a local area Ethernet network (100+Mbps).  After waiting 30 mins or so we
> get broken pipes and/or timed out connections.
>
>  The ontology loads if the MySQL database is accessed across the network
> directly without using the client-server (.pprj file is on the client side
> but points to a MySQL database hosted on the network)
>
>  Therefore the culprit seems to be network demands of the rmi server.
>
>  We have  -Dserver.use.compression=true turned on at the server.
>
>  We've tried -Dserver.client.preload.skip=true on the client side.
>
>
>  It seems this 25,000 frame ontology might be too large for the RMI
> client-server architecture, but the Protege documentation seems to hint
> that much larger ontologies have been developed using Protege.
>
>  Questions:
>
>  1. What is the practical scalability limit of the Protege RMI
> client-server in terms of ontology size?
>
>  2.  Are there additional configuration settings that we can try to get
> our ontology to load?
>
>  3.  Are there other collaboration models we could try for allowing
> multiple people to work on a large scale Frames ontology besides the rmi
> client-server approach?
>
>  Thanks in advance for your help.
>
>  John
>
>
>
>
> _______________________________________________
> protege-discussion mailing listprotege-discussion at lists.stanford.eduhttps://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
>
>
>
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing:
> http://protege.stanford.edu/doc/faq.html#01a.03
>
>


On Sat, Jun 22, 2013 at 12:49 PM, Timothy Redmond <tredmond at stanford.edu>wrote:

>
> This type of performance problem is a tricky area and to understand it
> better we would have to understand exactly where the bottleneck is.  But my
> first questions would be how large is the pprj file and what version of
> Protege are you using.  We made a change to Protege recently that optimizes
> how the .pprj part of a frames project is loaded by the client.  Using the
> very latest version of Protege may dramatically improve the startup
> performance if the pprj file is large.
>
> If moving to the latest Protege is not sufficient then you could send me a
> copy of the ontology so that I could see the performance issue and find the
> bottleneck here.  If you send the ontology out of line I can keep it
> private if needed.
>
>
>
>  Therefore the culprit seems to be network demands of the rmi server.
>
>
> This sounds like a simple
>
>
>
> 1. What is the practical scalability limit of the Protege RMI
> client-server in terms of ontology size?
>
>
> The server-client is used with ontologies of over 128K classes.  In this
> example the ontology is also a mysql database project.  So the 25000 frames
> you describe is not that large.
>
>
>
>  2.  Are there additional configuration settings that we can try to get
> our ontology to load?
>
>
> It has been a long time since I worked on the protege 3 client server but
> I think you have found the main options.  But you should also be warned
> that
>
>             -Dserver.client.preload.skip=true
>
>
> might work against you.  You save time on the preload but all the
> operations thereafter are slower until the client side cache has been
> sufficiently built up.
>
>
>
>  3.  Are there other collaboration models we could try for allowing
> multiple people to work on a large scale Frames ontology besides the rmi
> client-server approach?
>
>
> You could also try webprotege.
>
> -Timothy
>
>
>
>
> On 06/19/2013 10:26 AM, John Pierre wrote:
>
>   We are trying to set up a collaborative installation so multiple
> developers can edit a Frames ontology.  The ontology currently has about
> 25,000 frames.
>
>  We have successfully configured the RMI server and can connect clients to
> the server and access the example ontologies across the network.
>
>  The problem is that our 25,000 frame ontology isn't able to load into the
> clients when accessed across the network.
>
>  Our ontology is MySQL backed.
>
>  The ontology loads fine when accessed on the same machine without going
> through the rmi server.
>
>  The ontology loads but takes several minutes to do so when running the
> client and server on the same machine through the localhost loopback.
>
>  The ontology loading hangs and cannot load when running the client and
> server on different machines either on a wide area network (20+Mbps) nor on
> a local area Ethernet network (100+Mbps).  After waiting 30 mins or so we
> get broken pipes and/or timed out connections.
>
>  The ontology loads if the MySQL database is accessed across the network
> directly without using the client-server (.pprj file is on the client side
> but points to a MySQL database hosted on the network)
>
>  Therefore the culprit seems to be network demands of the rmi server.
>
>  We have  -Dserver.use.compression=true turned on at the server.
>
>  We've tried -Dserver.client.preload.skip=true on the client side.
>
>
>  It seems this 25,000 frame ontology might be too large for the RMI
> client-server architecture, but the Protege documentation seems to hint
> that much larger ontologies have been developed using Protege.
>
>  Questions:
>
>  1. What is the practical scalability limit of the Protege RMI
> client-server in terms of ontology size?
>
>  2.  Are there additional configuration settings that we can try to get
> our ontology to load?
>
>  3.  Are there other collaboration models we could try for allowing
> multiple people to work on a large scale Frames ontology besides the rmi
> client-server approach?
>
>  Thanks in advance for your help.
>
>  John
>
>
>
>
> _______________________________________________
> protege-discussion mailing listprotege-discussion at lists.stanford.eduhttps://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
>
>
>
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing:
> http://protege.stanford.edu/doc/faq.html#01a.03
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/protege-discussion/attachments/20130623/a7fb0397/attachment.html>


More information about the protege-discussion mailing list