Opening connection is slow

This sounds network related. There really is not anything that needs configured on the cluster other than the IP address / DNS names. If you are able to eventually connect then there is something causing latency in the network path - perhaps some form of filter / routing issues?

Thanks for your quick response.

I will let our customer know what you suggest and hopefully it helps.

As far as I know the Centera and the application server are connected with a glas fiber connection somehow. I believe using a backbone and no direct connection - as the Centera is used from other applications also but using the C SDK and not the XAM interface.

What we also could find out that if we try to open the connection without the .pea file the connection is established within 3-5 seconds but without permissions to do anything on the Centera. This I think is something strange.

Hartmut

I have attached a sample LOG file that we create with our own test tool using the same XAM interface we also use in our software. We have used this tool to access the Centera in US as well as on our customer site.

There are a couple of non interesting informations in the file but here we have all response times included for any operation we perform.

Hartmut

Accessing the .pea file should not be an issue as it is stored on the local harddisk of the application server.

Once the connection is established we can successfully write, read, delete files in an appropriate time frame within a few milliseconds to 2-3 seconds depending on file size, e.g. writing 20MB file (for test purposes we used only 1 single thread) took 2 seconds.

We would not have a problem in our application writing files to Centera as this is a Windows service, where the connection will be opened just once and then kept until process is finished.

But we also have the reading app which is a WEBService where we have to deal with timeout settings. So we would have to close and re-open sessions from time to time as session timeout occurs and new users trying to access files which are stored on the Centera. This would end up in not acceptable response time at least for the first user after closing the connection or the first user using the service after a restart of the system.

Hartmut

Having looked at your application log file, the performance figures (other than the initial connection) do seem typical of what would be expected.

You mentioned that connecting without any PEA file is fast, so it might be worth checking this out using the shXAM tool. Try connecting that way and then authenticating to the cluster using the PLAIN authentication method and providing a valid profile / secret combination. If the long delay moves to this part of the process then this points to some issues with the actual authentication process on the cluster rather than anything related to the PEA file.

Does the PEA file contain information for multiple clusters e.g. secondary or replica ones?

That is very strange indeed! Could it be that the delay is being caused by difficulty in accessing the PEA file, or file / operating system resource issues while accessing it?

Once a connection is established with the PEA file, are the API operations performing in the expected time scales i.e. sub-second for creating and opening clips etc?

I will pass this information to our customer, as we are very limited and do not get any userids/passwords which are included in the .pea file. This will probably take some days before I get some feedback, but will anyway try to get this test done a.s.a.p..

I know that there is another Centera located at a different location where we will not get any access to which is a backup Centera for the one we are dealing with. I'm not sure if this constellation is making the trouble or not.But I think we will at least find out into which direction the customer should look to fix it.

As soon as I get some feedback I will write this down for you and all others which may at some time have a similar problem.

Is there a firewall between the application server and the replica centera?  If so the app server MUST have a path through to the replica otherwise when the SDK attempts to open the replica it will time out causing long open times

Actually I don't really know if this is the case, but will forward your question to our customer.

Anyway the same cluster is used for another application also (using the C SDK I believe, but I'm sure it's NOT XAM). At least we haven't heard of any problems like this from the other application.

I will also try to get some customer contact joining our discussion during next week, while on Monday we already have announced to prepare all testing Programs on their own server so they can test everything on their own without the need giving us secure informations.

I hope that after this we will get a more clear picture about the things behind and I will post things here as soon as they are available.

Hartmut

Today I got the information that using a regular ping command to the Centera responds within milleseconds, while using the CenteraPing tool still takes the 14-16 seconds.

Using the shXAM tool requires the username and password which we don't get. The customer also did not test it yet.

However they have said that they will now open a support incident at EMC with all the information I provided and the relevant hardware and software informations from the customer installation.

Anyway thanks for all your informations you provided. I still will write down the results as soon as I get some more informations.

Hartmut

Hello Holger,

this was the exact problem. Meanwhile the customer together with some enployess from EMC have solved this problem by verifying and changing the configuration.

The replication system was not really seen from the initial system which caused the delay. So we are very happy to get good access times now and have at least pointed out the correct direction.

Tanks to all helping people!