I know that this has been briefly discussed in another post but @KarishmaAnthony please can you carry out the same comparison tests on a win7, i7 pc (3-4 years old), with 24GB RAM and a standard HDD, using a 1mb file. The origianl tsts are al your blog at https://communities.bentley.com/products/microstation/b/microstation_blog/posts/performance-enhancement---file-opening-time-for-microstation-connect-edition-update-13-vs-v8i-ss4
I would suggest that this is a more realistic test. Look forward to your revised tests.
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?
Stuart (and all), we are still working on additional tests, but what we have experienced so far is that v8i is on average 3 seconds faster in cold starts, regardless of the file size. We tested a 20mb dataset made up by 30 references, all smaller than 1mb.
Now, with larger datasets, these 3 seconds are more than compensated by CE faster 64btis data handling, so that with datasets larger than approximately 200mb CONNECT Edition is faster.
The above is for cold starts, in warm starts the differences we are seeing are either negligible or CONNECT Edition is faster.
We have asked several times, including in this thread, if any of you, who are being affected by these performance issues, could privately share his/her datasets for expanding our test plans and investigate additional cases that could be affected by slower performance that we can't currently reproduce. We got no responses to our call for more data, even though thus would be completely private, used solely for our internal testing and covered by NDA.
We have tested a machine with lower specs (i7, 16GB of RAM, HDD) than the one used for the original post but the differences are not significant for small files and datasets. The number of cores or amount of RAM doesn't show significant differences when opening small datasets, the differences between v8i and CONNECT Edition, that we can measure with our test cases, seem to be as I described above. Also using an HDD or an SDD won’t make much of a difference when testing performance differences between the two versions as both do benefit by the much faster SSDs when available, in case of a spinning drive they would both be slower and the 3 seconds difference in cold starts would be marginally longer.
As I said, all of the above is part of ongoing efforts to both improve our tests and MicroStation CONNECT Edition's general performance so it is not final. We will write a new post or update the existing one when we have completed and - again - please, help us by sending some of the data you are using as the basis of your complaints.
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?
~HTH
John.
yep
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.
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.
Brian MacCartney
Senior Designer, Electrical
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.