The Essential Project Forum

There's a topic in this forum about the client and server taking a long time to connect. Rather than take that topic off course, I thought I'd start a new one to cover some options for how we can tune the way the Protege client and server communicate.


I've been looking into various tuning properties that are available for Protege and some of these provide scope for tuning performance, which I thought might be worth exploring to if it seems that the Client / Server performance is low.

From the Advanced Client Server Tutorial for Protege Client Server

There is another setting that can be very important for performance:

Code: Select all

-Dserver.use.compression=true

This option enables compression on the client-server connection. It will increase the cpu usage on the client and the server but can provide quite a significant improvement in bandwidth usage (early experiments suggest a compression factor of up to 10 to 1 and performance on the client is doubled for some large ontologies).
Finally, the option:

Code: Select all

-Dtransaction.level=...

... controls the level of protection associated with transactions. The options are:

• NONE - which means that transactions do not even have rollback capabilities. This is not recommended.
• READ_UNCOMMITTED - which means that users can see other users changes even if the other user is in a transaction and has not committed the transaction.
• READ_COMMITTED - which means that user operations made during a transaction are not seen by other users until they are committed.
• REPEATABLE_READ - which means that the system assures a user in a transaction that data he reads will not change for the duration of the transaction.
• SERIALIZABLE - which means that transactions are serializable. This is the most stringent form of transaction processing but it is also the most expensive and the most likely to cause problems with locked databases.

There are also some properties that control the level of instance pre-loading that the client does that may also be worth exploring.

Jonathan

Hi Jonathan,

I uncommented the line
set "PORTOPTS=-Dprotege.rmi.server.port=5200 -Dprotege.rmi.registry.port=5100"

now i am getting the following error when i run run_protege_server.bat file

"SEVERE: Server startup failed -- java.io.IOException: Could not connect to the rmi registry task"

OK, note that this particular option should only be used if you are working through a firewall.

If that's the case - and your server is behind a firewall or you need to change the ports that the client and server are using due to a port clash on your network, see this post.

If you're client and server are not running through or you do not have a port clash, I would recommend that you re-comment that statement to put things back to the defaults.

As some background, what this has done is told the Protege Server to look for the RMIRegistry on port 5100 but unless you've changed the RMIRegistry port (as described in the article linked above) then it's going to be listening on port 1099, still. Hence the exception you're seeing.

If you're still seeing performance issues on the initial connection between the client and server (as per another topic) I would first look at the size of the repository that you are serving and resolving any issues in the metaproject that might be causing the server to be attempting to connect to resources that it cannot find.

Hope this helps
Jonathan