Simple question, complex answer:
I want my shared organisation configuration on a shared read-only network share. Its placed on an SSD with gbit ethernet, and i cant manage to make it function fast. Its 10-20 times slower compared to place it on a harddisk on the computer locally. I can clearly see Bentely allow for this functiuon, but is it not supposed to work faster?
Hi Victor,
Victor Bergman said:Its 10-20 times slower compared to place it on a harddisk on the computer locally.
What exactly does it mean? What is 10-20x slower? What operation?
To discuss the issue and its solution, to specify benchmark including metrics is necessary.
Victor Bergman said:but is it not supposed to work faster?
I think there are (at least) two different answers ;-)
If "faster" is understood as "faster than local workspace", I agree with Kevin van Haaren that in the case of shared workspace the priorities and reason why they are used are different.
But, when "faster" means "what should be done to make performance better", the answer becomes much more complex. The raw speed of disk (read/write IO) and network itself (MBits/second) is only smaller part of the whole situation. The network communication is complicated multilayered and multi-step process, so to cooperate with network administrators is recommended.
In my opinion to verify things like how fast network names are recognized and translated to IP addresses, whether any analytics is done because of intelligent managed router is used, whether there is any prioritization in network and or server, if any configuration can be changed on server (caching often accessed files...) etc. should be discussed with network professionals.
MicroStation (and other products like ORD even more) is specific in the way that workspace consists from many (in the case of civil workspaces thousands) of files, accessed frequently. So configuration, slowing down network communication on some or more layers, may be not visible when single documents are shared (like Office ones), but can cause problems when many files are accessed at once by one client.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Hello Jan,
Sorry for the oversimplification, and thank you for your great answer.
To be a litte more specific, the organization folder contains 20 DGNLIB files average 2 mb per file, and 20 txt files, average about 400 kb per file.
If we read/write these files, they takes the server and the pc about 5 sec to transfer average, in any way we try via the SMB protocol.
MicroStation takes 10 sec to open if the organization is placed locally, and about 150 sec if placed on the network.
I actually tried with an organization without any files, but only folders, and It took the same amount of time.
I know it might not be detailed enough, but i feel like the fact that they are not locally stored, that there is a bottleneck somewhere, and the numbers don’t add up for me. Does this help to produce a theory?
Victor Bergman said:To be a litte more specific, the organization folder contains 20 DGNLIB files average 2 mb per file, and 20 txt files, average about 400 kb per file.
It sounds like "nothing exceptional", complete civil workspace are far more bigger (both in terms of number of files and overall size).
Victor Bergman said:If we read/write these files, they takes the server and the pc about 5 sec to transfer average
Do you mean 5 seconds to handle all organization files, when e.g. copied to server together?
Victor Bergman said:in any way we try via the SMB protocol.
Unfortunately it is beyond my knowledge, what should be checked when SMB is used and whether better alternative exists. I remember, when Windows Server is used, there were "wrong combinations" of Windows client and server versions and specific fixes had to be applied.
Victor Bergman said:I actually tried with an organization without any files, but only folders, and It took the same amount of time.
It sounds like the access to network itself is slow.
Victor Bergman said:Does this help to produce a theory?
In my opinion there are several things you can try:
Although you indicate the problem exists with no dgnlib files loading, 2MB per dgnlib for 20 dgnlibs seems very excessive. Although we occasionally have dgnlibs of that size we do not regularly have them that large. If you look at all the dgnlibs that ship with ORD 10.12 Default Standards you'll find of 51 dgnlibs only 8 are > 1mb.
I suspect you have a lot of deleted elements being carried from dgnlib to dgnlib. You might try compressing your dgnlibs, just be very careful about it. I go tot the compress options, turn off all options, then do the compress. The reason to be careful is that frequently dgnlib standards aren't "in use" and will get removed by a compress. Levels in a level library typically aren't in use so if you turn on remove unused levels you can blow away all your levels (make a backup of all the dgnlibs before doing this as well!)
A couple of other things that can help with workspace performance (although again, the fact that it also occurs with empty folders may mean these aren't issues):
The MS_DGNLIBLIST specialized variables are:
# MS_DGNLIBLIST_CLASH # MS_DGNLIBLIST_DETAILINGSYMBOLSTYLES => DGN libraries for Detailing Symbol Styles. If this configuration variable is not defined, then the DGN library files will be taken from the MS_DGNLIBLIST_DRAWINGSEEDS configuration variable. If MS_DGNLIBLIST_DRAWINGSEEDS is also not defined, then the DGN Llibrary files will be taken from the MS_DGNLIBLIST configuration variable. # MS_DGNLIBLIST_DIMENSIONSTYLES => DGN libraries for Dimension Styles. If this configuration variable is not defined, then the DGN library files will be taken from the MS_DGNLIBLIST configuration variable. # MS_DGNLIBLIST_DISPLAYSTYLES => DGN libraries for Display Styles. If this configuration variable is not defined, then the DGN library files will be taken from the MS_DGNLIBLIST configuration variable. # MS_DGNLIBLIST_ELEMENTTEMPLATES # MS_DGNLIBLIST_DRAWINGSEEDS => DGN libraries for Drawing Seeds. If this configuration variable is not defined, then the DGN library files will be taken from the MS_DGNLIBLIST configuration variable. # MS_DGNLIBLIST_ITEMTYPES => DGN libraries for Item Types. # MS_DGNLIBLIST_LEVELS # MS_DGNLIBLIST_LINESTYLES => DGN libraries for Line Styles. If this configuration variable is not defined, then the DGN library files will be taken from the MS_DGNLIBLIST configuration variable. # MS_DGNLIBLIST_LINKS => DGN libraries for Sheet Indexes and Link Sets. # MS_DGNLIBLIST_PRINTING => DGN libraries for Print Styles. # MS_DGNLIBLIST_RENDER => DGN libraries for Rendering Setups, Materials, and Lights for your current session. # MS_DGNLIBLIST_TEXTFAVORITES => DGN libraries for text favorites. If this configuration variable is not defined, then the DGN library files will be taken from the MS_DGNLIBLIST configuration variable. # MS_DGNLIBLIST_TEXTSTYLES => DGN libraries for text styles. If this configuration variable is not defined, then the DGN linrary files will be taken from the MS_DGNLIBLIST configuration variable. # MS_GUIDGNLIBLIST => DGN libraries for tool, toolbox, task, menu, and icon customizations. # MS_COLORBOOK_LIBRARIES => DGN libraries for color books
The way these help is by limiting the number of dgnlibs that need to be examined to find resources. For example, you have 20 dgnlibs. if all you do is:
MS_DGNLIBLIST > /path/to/dnglibs/*.dgnlib
Then when MicroStation (or whichever product) needs levels it scans through all 20 dgnlibs. However if all your levels are defined in 1 dgnlib, you can do:
MS_DGNLIBLIST_LEVELS > /path/to/dgnlibs/levels.dgnlib
Now when microstation needs levels it only looks at the one dgnlib. much faster.