Performance Enhancement - File Opening Time for MicroStation CONNECT Edition Update 13 Vs V8i SS4

Are we going to get a response to this 

stuartw said:

Are we going to get a response to this 

And not even a reply to say that Bentley are working on this, with a progress update. If nothing else it's just disrespectful!! 

When are we going to get the new test results for more realistic pc spec and file sizes?

Hi Marco,

Thanks for the efforts.

Are you all testing with remotely located configurations? I know networks can vary greatly by location but I think that most users would be using a configuration stored on a server with different levels of CFG and DGNlibs being read.

One of the things that I have noticed is that MicroStation now seems to read all cfg (organization, workspace, workset) files when it is first opened. This maybe be some of the delays. I believe this to be the case based on if I have MSTN open and have WorkSpace 1 / WorkSet 1A active. I then make edits to WorkSpace 2 WorkSet 2A or WorkSet 1B and set 2,2A or 1,1B active I am required to restart MSTN to have any of the changes take effect. We are also using MSTN with a Civil configuration which adds the additional WorkSpace component of Civil Org.

Bentley has our configuration for testing. I can send you a link if you would like.

Also are you testing the files local or on the network? I know that network speeds vary from location to location and I am sure Bentley has a super fast network. I know that our users are opening files from a server via a mapped drive. Is this variable in your testing?

Marco Salino said:

with datasets larger than approximately 200mb CONNECT Edition is faster

That surely contradicts the performance blog by Karishma Anthony?

Hi Jon, sorry I haven't been clear in wording the post. What I meant is that with larger datasets, the difference I mentioned is counterbalanced by the 64bits benefits, until CONNEC Edition becomes faster. You are right, on Karisma's blog CONNECT Edition "overtakes" V8i with larger datasets but we have been trying different datasets, configurations and hardware and in some cases  CONNECT Editions becomes faster with smaller datasets.

As I mentioned, we haven't finished yet so please take my response as an update on a work in progress effort.

Hi John, the tests we have been running are mainly on local files. As you mentioned networks introduce an additional layer of variance, which makes even harder reproducing specific issues on our end. It would be great if you could share a link to your dataset and configuration privately with me so that we can be sure to test the right configurations.

We will do all we can to optimize MicroStation CONNECT Edition so that the impact of complex and multi-disciplinary configurations can be minimized.

Thanks Marco.

I sent you a link to the download.

Marco Salino said:

We will do all we can to optimize MicroStation CONNECT Edition so that the impact of complex and multi-disciplinary configurations can be minimized.

I would think this to be more real world testing.

Thanks Marco.

I sent you a link to the download.

Marco Salino said:

We will do all we can to optimize MicroStation CONNECT Edition so that the impact of complex and multi-disciplinary configurations can be minimized.

I would think this to be more real world testing.

We do what we refer to as a "robocopy" process.  All the configuration files. be they from a client or in house are copied down from the server to the local PC.  Any changes that have been made to the configuration is uploaded to the "MASTER" configuration file location on the server by the CADD manager if a change is needed.  If a file on the server is updated or newer than the copy on the local PC it will be copied down from the server and replaced.  If the file on the PC is newer than the copy on the server it will be replaced, because the copy on the server is the Master and is the Official version of it. 

All our drawing files are located on the server.  All the configurations and the program are on the local PC drive.  Only the Master on the server is the correct configuration version.  If any file is changed it has to be changed on the server in order for it to migrate to the local PC drive. This permits everyone to be working with the same configuration at all times.

Used to do the same Brian, but with network speeds being the way they are have seen no real speed difference having the build on the server and it's a lot less network traffic and our build is far from small. What IS a big time saver is to have the user files locally. 

In the past I used to setup overnight robocopy jobs for the same reasons. 10 years ago, even with good SANs and networks, it was hard to keep perofrmances up to pace with 350 architects working on several projects. Nowadays though, this should be well possible using modern hardware but still the use of robocopy can be very valid if setup correctly and if it helps with network latency or other issues.

I also remember that most of my users at the time NEVER shut down their machines, unless we forced them to do so, so they would rarely do more than one cold start a day, in which case a couple of seconds extra opening time were not an issue and went pretty much unnoticed.

That's correct John but we need to understand all the factors that may be playing a role in the issues here reported, so testing a wide range of real-world datasets on local disks and without configurations is needed to investigate performance issues related to data loading.

Ok Marco...