Jump to content
  • 6

Vectorworks Cloud Services Project Sharing Server


Christiaan

Question

23 answers to this question

Recommended Posts

  • 0
  • Vectorworks, Inc Employee

The main issue PSS (Project Sharing Server) is trying to solve is the access and modification of the project file. The project file can be stored on different platforms (network drive, on Mac, Windows, Linux, Synology device etc.). That file being accessed by different platforms (Mac and Win) simultaneously often left the project file in a broken state (locked, partial etc.). PSS orchestrates the access to the project file and avoids conflicts and locks.

When using cloud providers that issue is not there, as everyone has a local copy of the project file and the modifications to it are done on the same machine and platform. Changes to the project files stored in cloud providers are orchestrated by other service that has been there and tested for a number of years now.  I would say that both solutions are robust and there is no compromise with reliability when using cloud providers. 

There would be no difference in sync speed. VCS sync is now fast using LAN sync (for users in the same local network), delta sync and regional storage (Migrating where your cloud data is stored can significantly improve sync speed. That can be changed here https://cloud.vectorworks.net/portal/account/) 

PSS is to be used in companies with very strict security rules where Internet is highly restricted or companies that do not trust cloud providers to store their data.  

If that is not the case and you are comfortable with storing your project files in cloud providers then there are no drawbacks of using PS with VSS over PSS. 

 

  • Like 2
Link to comment
  • 0

Hi Lyuben, thanks for this very illuminating explanation. I had wrongly thought that there was more to it than cross-platform compatibility.

 

So, in theory, are there any *potential* advantages to a server model over a file-sync model?

 

Take, for example, a theoretical future feature where the server can render Sheet Layer Viewports in the project file and then we can sync those rendered viewports to our working files. Would there be any advantage to a VCS project sharing server over VCS file-sync to enable this feature?

Link to comment
  • 0
  • Vectorworks, Inc Employee

Hi Christiaan, probably there might be some advantages of the server model, but nothing major that I can think of. In general VCS can also be considered a server model, because the copy of the project file that is stored on the cloud can be treated as the server copy.

 

I think that updating the Sheet Layer Viewports and syncing them back can be done easier using VCS, because VCS has the whole infrastructure and servers running Vectorworks already in place that can render the viewports and update them. 

To sum it up: project sharing server is good for users that do not want their project files stored on the cloud and solves technical issues that are not relative for cloud providers. 

  • Like 3
Link to comment
  • 0

Thought I would cross link the below related thread...

 

 

As I noted in the above linked thread, I think it would be quite valuable for the developers to consider improving upon the Project Sharing Server to optimize it for remote access.  I think it has the potential to make project sharing a much better experience, particularly when you get more than a few users sharing a project file.  We've been using Revit Server like this for a little while now and it has been splendid.  The benefits over file based sharing with something like Dropbox become magnified the more users that are sharing the project file.

Link to comment
  • 0
3 hours ago, Doubledge said:

Hi @Christiaan. The short answer is no.  I have actually found worse performance so far from using the Project Sharing Server on a cloud server.  I discussed this a little in the below thread.  Basically we see a lot of lagging or delays as we work on a file.  This gets progressively worse the more network traffic there is, as one might expect, but to a degree that illustrates it was not made for this kind of setup.  We suspect VW is connecting / communicating with the server so much that any change in latency, even minor, cause short pauses, which are simply maddening.  It's unfortunate because we have otherwise seen fewer other issues that we persistently deal with when using Dropbox and file based sharing, such as unreliable project file commits and locked project files.  These things get worse the more people you try and share a project with.

 

Well that is certainly something to write home about. And it makes sense in my mind that there is the potential to experience fewer issues when using a server architecture over file sync. File sync relies on a third party. Cut that third party out of the equation and rely fully on a server developed by Vectorworks and that's surely got to mean more control over quality assurance.  @Lyuben is this a fair comment?

 

3 hours ago, Doubledge said:

I think it would be quite valuable for the developers to consider improving upon the Project Server to optimize it for this kind of cloud installation.  I think it has the potential to make project sharing a much better experience, particularly when you get more than a few users sharing a project file.  We've been using Revit Server like this for a little while now and it has been splendid.

 

 

We've had pretty good experience with file sync on both Dropbox and Resilio, but I have to admit that most of that good experience involves very few concurrent users. Anything over 2 users can get a bit wobbly.

Edited by Christiaan
  • Like 1
Link to comment
  • 0
  • Vectorworks, Inc Employee
20 hours ago, Christiaan said:

We've had pretty good experience with file sync on both Dropbox and Resilio, but I have to admit that most of that good experience involves very few concurrent users. Anything over 2 users can get a bit wobbly.

I think that the wobbly experience is not due to the specific sync technology - either cloud or project sharing server. It is more because of the way Project sharing works right now - many users modifying and having access to the same file. The larger the file and the more users tend to degrade performance. 

My take on deploying PSS on AWS - it is a good exercise, but not sure it can bring improvements. 

Link to comment
  • 0

Thanks for the insight @Lyuben.  It was an interesting experiment setting up PSS on an AWS server.  I had high hopes since we've had such great success doing this with Revit and Revit Server.  I have to say that other than the performance issue we saw while working in a file, as I noted above, VW worked quite well seemingly solving all the other "wobbly" issues we normally deal with while using Dropbox and file syncing.  This gives me some hope for future improvements.  To that end I hope you guys are considering how PSS and project sharing in general might be enhanced to overcome this.

Link to comment
  • 0
  • Vectorworks, Inc Employee

Your biggest performance bottleneck is always going to be copying the file from editor to server, then back out to all the users.  Any flavor of cloud service, that syncing is going to be triggered immediately by the service. So the more people in one location without something like Lan Sync, the bigger the chance you're saturating the network between the cloud and that group. And the more editors, or the closer in time those changes are, again, all roads leading toward network traffic. 

 

When sharing a file on a server, obviously you're still pushing changes back and forth between the editor and master project file, but it no longer needs to broadcast copies out to everyone so the network performance demands aren't as great.

 

In both cases, there's the coordination for when the project is ready and able to be physically changed on disk. For a server, that's just that the file is idle. Then the editor can refresh the working file and commit.  For cloud, a user might think that's all they are waiting for...the file to be idle. But it is also conflated with the extra cost of waiting for the cloud to sync the local cloud copy of the project up to date before you can even start.  Many changes in a short period of time, and each change by another editor moves the goalpost of when the local project is finally ready. 

  • Like 2
Link to comment
  • 0
  • Vectorworks, Inc Employee

@Christiaan @Doubledge I presume you are already doing this, but in my experience (for project teams of three or more), syncing is greatly assisted by communication within the team to establish:

  • Scheduled syncing times (typically refreshing sync changes first thing in the morning, and then saving and committing before lunch and at the end of the work day), with team members giving each other notice of their syncing.
  • a layer structure that allows the checking out of whole design design or sheet layers. (Sheet layers can be an issue when attempting to update Title Blocks en masse, but is something that is easily negotiated between the team).

And yes, I would recommend the use of VCS project sharing. (In my experience, it has been more reliable than Dropbox.)

  • Like 1
Link to comment
  • 0
On 12/21/2022 at 4:39 PM, Rick Berge said:

In both cases, there's the coordination for when the project is ready and able to be physically changed on disk. For a server, that's just that the file is idle. Then the editor can refresh the working file and commit.  For cloud, a user might think that's all they are waiting for...the file to be idle. But it is also conflated with the extra cost of waiting for the cloud to sync the local cloud copy of the project up to date before you can even start.  Many changes in a short period of time, and each change by another editor moves the goalpost of when the local project is finally ready. 

Rick, but isn't the "editor can refresh the working file" (file server) vs "sync the local cloud copy" + refresh (file sync) effectively the same thing? In that the file server user needs to wait for the data to download/upload when they hit refresh*. Whereas the file sync user has the data local to their volume after the file sync, so the refresh should theoretically be quicker. With overall similar waiting times?

 

* I'm talking about a hypothetical over-the-internet project server here (not LAN)

Link to comment
  • 0

I think what Rick is saying is that with a cloud based file service like Dropbox there is essentially more syncing happening because not only are the changes being sent back and forth between working files and the project file but the project file, and sometimes both files, are then also being sync'd in both locations.  That project file has to exist on everyones computer.  In addition, the Project File is only able to be updated by one working file at a time in this setup.  With the server application the project file only exists on the server and the working file only exists on the users computer. Only the changes are sent back and forth while also being able to support multiple working file updates at a time.

Edited by Doubledge
  • Like 1
Link to comment
  • 0
9 hours ago, tdiamond said:

@Christiaan @Doubledge I presume you are already doing this, but in my experience (for project teams of three or more), syncing is greatly assisted by communication within the team to establish:

  • Scheduled syncing times (typically refreshing sync changes first thing in the morning, and then saving and committing before lunch and at the end of the work day), with team members giving each other notice of their syncing.
  • a layer structure that allows the checking out of whole design design or sheet layers. (Sheet layers can be an issue when attempting to update Title Blocks en masse, but is something that is easily negotiated between the team).

And yes, I would recommend the use of VCS project sharing. (In my experience, it has been more reliable than Dropbox.)

Yes, we certainly make an effort to be as disciplined and structured as possible but it rarely works out like you describe in reality because there are just too many dependencies, both physically within VW and in general with project workflows, time tables, manpower, etc, to feasibly keep it this strict. 

Edited by Doubledge
Link to comment
  • 0
33 minutes ago, Doubledge said:

I think what Rick is saying is that with a cloud based file service like Dropbox there is essentially more syncing happening because not only are the changes being sent back and forth between working files and the project file but the project file, and sometimes both files, are then also being sync'd in both locations.  That project file has to exist on everyones computer.  In addition, the Project File is only able to be updated by one working file at a time in this setup.  With the server application the project file only exists on the server and the working file only exists on the users computer. Only the changes are sent back and forth while also being able to support multiple working file updates at a time.

But, with file sync, only the changes are synced as well, right? It's not syncing the entire project file after each save and commit.

 

So they (file sync vs file server over the internet) generate the same internet traffic.

 

With file sync, a save and commit is done on the local volume; only the syncing of the project file generates internet traffic, but it does that in the background. Whereas with a file server, the save and commit is the internet traffic. They're both transferring the same data but it probably takes longer to do the actual save and commit to a file server. With file sync, after a save and commit, you can carry on working straight away because the project file can sync in the background. But with a file server, the save and commit itself will take longer because it's being transferred over the internet.

 

So am I right in saying that file sync is faster if you're the user doing the save and commit (because it's done quickly on the local volume and file sync over the internet is subsequently done in the background); but, if you're waiting to refresh somebody else's save and commit, a file server is faster because the save and commit and upload to the server is one step, not two? @Rick Berge @Lyuben, have I got that right?

Link to comment
  • 0
Quote

So am I right in saying that file sync is faster if you're the user doing the save and commit (because it's done quickly on the local volume and file sync over the internet is subsequently done in the background); but, if you're waiting to refresh somebody else's save and commit, a file server is faster because the save and commit and upload to the server is one step, not two?

 

Correct.  This is what we experienced.  What I was trying to describe is as you noted, it's 2 steps for each user with file sharing.  This is what I mean by more syncing.  You have to commit those changes locally to the project file and then Dropbox has to upload the changes to that project file.  Then other users have to do this in reverse.  They have to download those changes to their local copy of the project file and then it can sync with the user file.  While DB is syncing those project file changes in the background it has locked the project file and other users can't sync, commit or even check out other items.  This doesn't happen with the server application.  In the end it's slower overall using file sharing from my experience with it.  

 

Quote

So they (file sync vs file server over the internet) generate the same internet traffic.

I have no idea if this is true as I imagine that it has a lot to do with the how each system chooses to package and transmit that information.  Interesting question though.

 

Edited by Doubledge
  • Like 1
Link to comment
  • 0

I think for PSS to be viable with a remote server they need to figure out how to resolve the lagging issue I experienced which made it impossible to work effectively.  PSS works best on a LAN server where your speeds are fast enough and latency low enough you don't experience any lags. Over a cloud connection it just doesn't perform well enough.  I can only speculate that it has something to do with how and how often it communicates with the server so even on VCS the server application would need to be improved somehow.  I would certainly give my vote for doing this.  I think the PSS direction is the better way to go.

Edited by Doubledge
  • Like 1
Link to comment
  • 0
1 hour ago, Antonio Landsberger said:

@Lyuben

Could you please define what
VCS sync, LAN sync, and delta sync

VCS sync = Vectorworks' own file sync service, similar in operation to Dropbox file sync (VCS stands for VW Cloud Services)

LAN sync = local area network sync, i.e. syncing over your local home or business network rather than the internet

Delta sync = is a file sync technology that will sync only parts of a file that have been updated or changed. Very useful when working with large uncompressed files like VW files

Link to comment
  • 0

Curious now that our Synology server has the Drive App to sync between user and server if we might be better off moving everyone to access via the app?

- Single solution works everywhere, no need to run project files a different way.

Also wondering if with that solution we make all projects, shared project files so the file sharing commands can use the key commands and not have to run a script to check which to run. 

 

Would give lots of nice redundancy to the data. 

Link to comment
  • 0
9 hours ago, Matt Overton said:

- Single solution works everywhere, no need to run project files a different way.

Also wondering if with that solution we make all projects, shared project files so the file sharing commands can use the key commands and not have to run a script to check which to run. 

That's how we're working now. We have a top level folder for all our VW files, subdivided into projects (so they're no longer nestled amongst all our other files/subfolders). All our VW files are Project Files, even the simplest ones. And all our files are on VCS.

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...