Performance issue when publishing repository to Viewer

[dagnils]

Hi,

I've setup an Essential Open Source environment in AWS with the following config:
- Windows Server (64 bit/8 GB RAM) hosting the Essential Server
- DB engine 4GB RAM, Aurora (MySQL 5.6 compatible)

The performance is great when publishing the repository to the Viewer from the Protege Client on the Windows Server (in AWS), but when I do the same procedure from the Protege client installed on my company network the publishing process takes approx 15 minutes before the reportXML.xml is published to the \webapps\essential_viewer folder on the server. The reportXML.xml is only 5MB.

Anyone have any idea why this takes so long?

Thanks and regards,
Dag Nilsen

[jonathan.carter]

Hi Dag,

Thanks for this. It sounds familiar to me, although it does seem to be taking longer than I have experienced before.

Let me start by confirming my understanding of your scenario.

• You have the Essential Open Source environment deployed to a Windows platform running on AWS.
• You have installed using the ‘multi-user’ pattern, running Protege Server on your Windows platform on AWS.
• When you publish to Viewer from Protege Client running on that Windows AWS platform (on the same host as the Protege server) performance is good.
• With Protege Client running locally (within your network) connecting to the Protege Server on Windows AWS the publish time is very poor.

I think there are two things that could be contributing to this poor performance.

1 Protege Client Server Connection
The Protege Client performs a lazy-load of the repository when running in client/server mode. However, in order to publish to Viewer, it must download the entire repository.
- When you run this process on the Windows AWS environment, are you running Protege in client/server mode?
- Or are you running a stand-alone Protege client running on that Windows AWS platform?

If it’s the former - that you tested Protege Client / Server all running on the AWS environment (effectively all ‘localhost’) - the first thing to check for is any firewalls or other network infrastructure that exists between the Protege Client and the Protege Server.

The Protege Client / Server connection is very ‘conversational’ with a high number of small exchanges between client and server. Protege was designed for a local network configuration and the interaction is not well-suited to running this in a cloud scenario.

2 Protege Server to Database Connection
Another thing worth checking is the database connection performance to make sure that it’s not the cause of the poor performance. However, that you’ve seen good performance when running everything on the Windows AWS environment would suggest that there is a good and efficient connection to the database.

Protege will automatically use HTTP tunnelling through a firewall to connect the Client to the Server but this could also be contributing to the poor performance. Unfortunately, the native RMI protocol uses a dynamically-managed range of IP ports, so this is not something that your security will open the firewall for!

Let me know what you find and we can move forward from there.

Jonathan

[dagnils]

Thanks for your reply, Jonathan.

It has to be something with the network config... I'll involve a network expert at work to analyze the network traffic between client network and AWS server network.

- Dag