CAD Forum

I am planning to set up a small PDM environment on a virtual machine on Azure (max 5ish active users).

It will most likely be hosted in region "Europe North" and connected to our corporate network and will be accessed from 2-3 locations in Europe. Not sure how the responsiveness would be but will test once it is set up.

Planned setup:
SOLIDWORKS PDM Standard 2022
Windows Server 2019
MS SQL Express 2019
2x vCPU + 8 GB ram (D2v3), and bump up to 4x vCPU + 16 GB ram (D4v3) if needed
2x 128GB Standard or Premium SSD (+ maybe some backup storage)

Any recommendations on virtual machine spec and other settings? Should DB and Archive server be separated? Any experiences with cloud-hosted PDM are appreciated.

We just put a similar setup in place. I can't add many details, the IT guy did all of the heavy lifting on the azure side of things.

All the info from PDM Pro docs recommend two servers: one for Archive one for SQL. Nobody went into specifics just said, "It's better if they are separate."
I'm very far from expert, but I've noticed a couple things over the past couple years that I relate to reason to have the separated.
1) SQL likes to gobble up most of the system memory. My lay understanding is SQL will cache the popular tables/functions/stuff in RAM to provide better performance. You can set the limit lower if you're sharing a system, otherwise it looks like SQL will consume about 80 - 85% of physical mem after it's been running for a while.
2) SQL server doesn't need much storage space (assuming you're moving the backup files somewhere else) and grows very slowly. The Archive server will need much more storage relative to SQL and will grow more frequently.
3) If you're doing replication the normal setup is multiple archives and one SQL server. Maybe there's a way to have replicated SQL Servers but if I understand correctly the redundancy is done in SQL and PDM is not aware of it. PDM only connects to one SQL server.

I am not sure about the Azure cloud hosted aspect, however systems specs for our items are as follows:

Virtual Environment: VMWare vSphere (ESXI) - 7.0 U3

Archive Server:
- 2 Virtual Core 2.1 GHz
- 16 GB RAM
- Windows Server 2019
- 100 GB Storage (OS Only)
- 1.1 TB Additional Storage (Archive files only)

Database Server:
- 2 Virtual Core 2.1 GHz
- 32GB RAM
- Windows Server 2019
- SQL Standard 2019 (latest cumulative updates installed, 14? I think)
- 100 GB Storage

This works well for 20ish active users at any given time.

The main reasoning behind separating the DB Server and the Archive server is that the DB gets a TON of traffic. Just browsing the vault and clicking on files gets lists of folders/files to display from the database in addition to data card information, contains, or where used information depending on what tab is active in your explorer window. This could adversely affect the available processing and RAM if you need to Get/Check-in a file that will require the Archive to transfer data to you. I'm sure this is only noticeable with larger user bases, however it's relatively simple to split them up in a virtual environment to separate servers.

bnemec wrote: ↑Wed Mar 02, 2022 10:23 am 1) SQL likes to gobble up most of the system memory. My lay understanding is SQL will cache the popular tables/functions/stuff in RAM to provide better performance. You can set the limit lower if you're sharing a system, otherwise it looks like SQL will consume about 80 - 85% of physical mem after it's been running for a while.

This is correct and by default the SQL server is setup to consume more RAM than is currently in most systems (2147483647 MB). It is recommended to figure out what the max settings should be based on your environment and use though, as SQL can end up consuming resources needed for other things on the system. This MS page has detailed information about SQL memory configurations. https://docs.microsoft.com/en-us/sql/da ... rver-ver15

bnemec wrote: ↑Wed Mar 02, 2022 10:23 am 3) If you're doing replication the normal setup is multiple archives and one SQL server. Maybe there's a way to have replicated SQL Servers but if I understand correctly the redundancy is done in SQL and PDM is not aware of it. PDM only connects to one SQL server.

This is not actually correct if you are using the PDM database replication feature (added in 2017). This feature uses Always On Availability Groups with SQL server to keep the databases in sync, but the PDM client uses connections to a secondary database for read only calls to speed up operations for clients who are far away or have a high latency to the primary SQL server. A secondary SQL server is configured at the user/group level and the PDM client will connect to the secondary server for all read only calls under specified conditions. All write operations still have to go back to the primary SQL server since all replicated databases are read only.

Diaval wrote: ↑Thu Mar 03, 2022 10:57 am This is not actually correct if you are using the PDM database replication feature (added in 2017). This feature uses Always On Availability Groups with SQL server to keep the databases in sync, but the PDM client uses connections to a secondary database for read only calls to speed up operations for clients who are far away or have a high latency to the primary SQL server. A secondary SQL server is configured at the user/group level and the PDM client will connect to the secondary server for all read only calls under specified conditions. All write operations still have to go back to the primary SQL server since all replicated databases are read only.

Thank you for the correction.

@SPerman
How has your PDM Standard been doing on Azure? Our company is looking to move from on-site servers to Azure in the next few months. Anything we should watch out for?

Thanks,
Carrie

I'm not a great test case. I am one user on one machine. About once a month (or three, if I am honest) I will clean up all of my checked out items. I'm not doing a lot of saving to and downloading from the server like one would be doing in a busier environment. Having said that, i don't have any complaints. I'm guessing a lot of it will depend on the quality and speed of the connection.

I don't think any of the software knows that it is running on a VM in the cloud as opposed to a server in a rack.

CarrieIves wrote: ↑Tue Oct 31, 2023 6:12 pm Anything we should watch out for?

Bandwidth.....bandwidth....more bandwidth

Our company moved the entire datacenter to Azure........for a large PDM installation like ours, its definitely slower. We went from local servers with 1ms of latency to Azure east servers with 40ms of latency, so to be expected I guess. Some of its bad enough that I have to use remote desktop on a server to make edits in the admin tool, especially to workflows as it takes forever to save. If I had a choice I would've kept the PDM servers on site but our global IT said no local servers anywhere...no exceptions. Maybe I should put this under the Pet Peeves post.

Probably you will be fine with so few users. DB require more memory and cpu, while a separate archive needs a fast RAID, cpu and memory are not so critical there.

so said I am against PDM on cloud for medium sized organizations like us. It is going ti end up trading server costs with engineers time. let alone security requirements, SLA with the provider, dedicated line with datacenter ...

It will be slower by design compared to an on premise solution.

If we were going there it would be better a radical approach and move all the workstations on the same cloud and lease some cheap laptops with a couple of screens in the office.

jcapriotti wrote: ↑Wed Nov 01, 2023 2:38 pm Bandwidth.....bandwidth....more bandwidth

On local, each computer got a 1Gb link to server. As long as switches are setup properly.
Off site, all cramp into one ~100MB internet with God know how many hops to the server.

Frederick_Law wrote: ↑Wed Nov 01, 2023 4:52 pm On local, each computer got a 1Gb link to server. As long as switches are setup properly.
Off site, all cramp into one ~100MB internet with God know how many hops to the server.

Yep, we used to hop through one switch to the server.......now its about 5.

I'm not totally against cloud servers. For most office stuff, you won't notice. But CAD programs that load assembly/part file references are extremely sensitive to it. PDM/Windchill helps though since the files are loaded locally....but there can still be a significant download/upload time due to data set size.

We will be upgrading from PDM 2020 to 2023 soon and there are supposed to be some performance gains in lower latency conditions......fingers crossed.

jcapriotti wrote: ↑Wed Nov 01, 2023 5:16 pm Yep, we used to hop through one switch to the server.......now its about 5.

I'm not totally against cloud servers. For most office stuff, you won't notice. But CAD programs that load assembly/part file references are extremely sensitive to it. PDM/Windchill helps though since the files are loaded locally....but there can still be a significant download/upload time due to data set size.

We will be upgrading from PDM 2020 to 2023 soon and there are supposed to be some performance gains in lower latency conditions......fingers crossed.

File transfers are nearly irrelevant IMO, it's the SQL chatter that kills me when I VPN from home. Maybe not every mouse click in PDM client creates SQL command (select, etc.) but it's much closer to all than half that do. So going from a consistent <~10ms latency to >~100ms latency makes PDM miserable IMO. Users don't notice a few 100ms delays in transferring a bunch of files. Users will notice hundreds of 100ms delays when trying to use the PDM GUI.

Now for those with slow upload speeds, like 5Mbps, they will suffer with check-ins. But that's more in the work from home realm, most business offices are spending the bucks for high speed up and down. If they aren't buying the high speed upload then they're behind the times and will be left in the dust of all the progressive companies that are buying cloud everything.

Solidworks PDM hits no where near the upload/download speeds that business internet service is capable of. It's a curious thing that it is so stubbornly slow when we can transfer packets to the server much faster when it doesn't involve PDM. In my experience the slow transfer speeds do matter. 1 MB/sec is terrible for a 50MB file. Compare to on-prem 50-80 MB/sec.

Brian-M wrote: ↑Thu Nov 02, 2023 6:28 pm Solidworks PDM hits no where near the upload/download speeds that business internet service is capable of. It's a curious thing that it is so stubbornly slow when we can transfer packets to the server much faster when it doesn't involve PDM. In my experience the slow transfer speeds do matter. 1 MB/sec is terrible for a 50MB file. Compare to on-prem 50-80 MB/sec.

Comparing PDM transfer rates for adding files to the vault vs uploading files to a network share is not an apples to apples comparison though. If PDM was just a simple file transfer it might be able to match a simple upload to the server. But there is a lot more going on when you are adding files to the vault.

In addition to the physical transfer of the files, the archive server is inspecting every known file type for metadata and for CAD files it's also extracting all of the reference information and storing all of this data in the SQL database. The read times for each file as well as the network traffic to the SQL server are additional consideration here. The advantages for getting access to all of the file metadata, CAD reference trees for BOMs, Contains and Where Used information, file versioning/revisioning, managed workflows, and granular permissions access are the benefits gained from dealing with transfer rates that are slower than a simple upload to a network share.

Thanks for that explanation Diaval.
I still have the question about why on-premise user to PDM server is so much faster, or over VPN is so much slower.

It has to do all the same work either way, but on-prem it can transfer over 50 MB/sec (I mean effective transfer speeds from the user perspective, like the whole check-in process is completed).

So is latency repeatedly taking a bite out of performance? For all those operations you mention it doing behind the scenes. Or is something fundamentally flawed about how Solidworks PDM handles VPN traffic?

My ping to server is 76 ms. My internet is fiber with hundreds of Mbps, with 8 ms general latency. My Get Latest speed is 1 MB/sec at best. (Seems like Get Latest would require fewer of the operations you mention.) Check-in is slower, more like 0.5 MB/s. Even our users closer to the server, with 30 ms ping, only Get files at 1.5 MB/sec using VPN. This is true if there are hundreds of small files, or one big file.

And to tie it back to the original post, using Azure is similar to using VPN. Get speed jcapriotti tested with Azure server last year was ~3 MB/sec.
viewtopic.php?t=2066

Brian-M wrote: ↑Fri Nov 03, 2023 12:56 pm Thanks for that explanation Diaval.
I still have the question about why on-premise user to PDM server is so much faster, or over VPN is so much slower.

How much traffic inhouse switch/network is handling?
How much does ISP/VPN handling?

2 lanes road with 30 cars.
6 lanes highway with 3000 cars.

Max speed means nothing when there is traffic jam.
On network, a jam means a message back to the source for resend.
Or no message cause timeout and resend.

VPN is the toll booth or tunnel.

Brian-M wrote: ↑Fri Nov 03, 2023 12:56 pm Or is something fundamentally flawed about how Solidworks PDM handles VPN traffic?

SW cannot change network protocol.
It's done by OS and hardware.

In general most programs are not written for files on network.
They all expect instant and 100% respond from hard drive.
Same with OS, Windows.

There are fundamental flaws with files on network. Works well as storage, not for access.
That's why we need to keep files on local and use PDM to manage user permission.

It's not just about latency to the archive server. The latency to the SQL server, the SNL server, and the Domain Controller can all play a role in how long PDM operations may take.

VPNs themselves can also actively interfere with file transfer operations, and in some cases can even cause data corruption.

it depends also by the SLA you have with your provider otherwise is full speed for your network on premise vs BEST EFFORT on the wan side. So you get the max speed of your internet connection once in a while as it is not guaranteed.

To make cloud works you have to pay more. for the virtualized hardware specs, for the minimum net speed between datacenter and your company. It goes for the worst scenario as well: let say for whatever reason your provider connection is down: what do yu do? close the company and everybody home?

like you buy a server or workstation with a support contract with 24h on site replacement you pay a premium according to the worst loss you accept to pay in case something goes wrong.

this is why I do not like to have critical data on the cloud.

Diaval wrote: ↑Fri Nov 03, 2023 7:14 am Comparing PDM transfer rates for adding files to the vault vs uploading files to a network share is not an apples to apples comparison though. If PDM was just a simple file transfer it might be able to match a simple upload to the server. But there is a lot more going on when you are adding files to the vault.

In addition to the physical transfer of the files, the archive server is inspecting every known file type for metadata and for CAD files it's also extracting all of the reference information and storing all of this data in the SQL database. The read times for each file as well as the network traffic to the SQL server are additional consideration here. The advantages for getting access to all of the file metadata, CAD reference trees for BOMs, Contains and Where Used information, file versioning/revisioning, managed workflows, and granular permissions access are the benefits gained from dealing with transfer rates that are slower than a simple upload to a network share.

Don't forget the file rename that occurs when copied from the Archive server. All files there are named by a version number and stored in a folder based on the document id in the DB. So imagine getting a large assembly and its associated files, after copying them, it has to rename them all. Then reverse that on check in.

mp3-250 wrote: ↑Fri Nov 03, 2023 5:47 pm close the company and everybody home?

We've already done that twice this year.

jcapriotti wrote: ↑Fri Nov 03, 2023 7:14 pm We've already done that twice this year.

So much "save the server costs" vibes

Sorry for the cheap sarcasm

mp3-250 wrote: ↑Fri Nov 03, 2023 8:11 pm So much "save the server costs" vibes

Sorry for the cheap sarcasm

No doubt my server costs are higher. I used to be able replace production server every 5 years, then rotate old servers to dev/test. But now I have to pay for all of them monthly in the cloud. Monthly cloud costs for one year for one server is the same as the 5 year cost of buying a new server. Now there are some infrastructure costs we are saving I suppose. But there is a time lost cost for longer wait times for end users that is difficult to quantify.

@jcapriotti there is a lot of cost obfuscation going on, like "a certain CAD package" and its bugs and regressions that cost us in term of lost productivity and damage to our data that require fixing them, but cannot be quantified so we cope silently and brush everything under the carpet.

it is indeed funny how mechanical design and production time and costs are strictly monitored up to X decimal places and still a software running costs are a sort of blackbox as it is offered "as is" with little to no guarantees that may (or may not) work.

Imagine your washing machine tellIng you "sorry today no pants washed. generic error LOL" or your car telling you to change your workflow in the middle of braking...

Your GPS take you around the block for 30 minutes because of "routing error"

mp3-250 wrote: ↑Mon Nov 06, 2023 4:23 pm @jcapriotti there is a lot of cost obfuscation going on, like "a certain CAD package" and its bugs and regressions that cost us in term of lost productivity and damage to our data that require fixing them, but cannot be quantified so we cope silently and brush everything under the carpet.

I get it, but honestly I feel all CAD software can be flaky depending on what you're trying to make it do. I can't think of one that I've used that didn't misbehave....SolidWorks, Catia, and NX. I've played around with Solid Edge but not really used it day to day....I did manage to crash it a few times just trying out features. Catia was old...v4....it would lock up our old unix workstations from time to time. NX didn't crash as often, but I would get some kind of error that wouldn't let me save....so still work lost. These were all various older version so no doubt things have changed.

jcapriotti wrote: ↑Wed Nov 01, 2023 2:38 pm Bandwidth.....bandwidth....more bandwidth

Our company moved the entire datacenter to Azure........for a large PDM installation like ours, its definitely slower. We went from local servers with 1ms of latency to Azure east servers with 40ms of latency, so to be expected I guess. Some of its bad enough that I have to use remote desktop on a server to make edits in the admin tool, especially to workflows as it takes forever to save. If I had a choice I would've kept the PDM servers on site but our global IT said no local servers anywhere...no exceptions. Maybe I should put this under the Pet Peeves post.

Bandwidth indeed. We had to switch our connection from a 200MB to a 1GB connection after we joined our companies to our server. Having 3 different locations accessing the server requires a lot of bandwith, especially if you start going with remote session and whatnot.