Performing a Latency Study in SOLIDWORKS PDM (Part 2)

In part one of our SOLIDWORKS PDM blog series, we learned about the topology of SOLIDWORKS PDM including the necessary terminology to better understand how the architecture or the various servers interact with each other and how numerous tests can be run to define these interactions. Now, let’s take a deeper look and put some real numbers to the interactions.

As users start to identify with latency a little more, they will find that only certain functions are impacted while others seem to be immune to latency’s effects. The real answer is that nothing is immune to latency, it’s just that many factors play roles in how this is able to happen. Sometimes it’s as simple as the server being hit the hardest by the user’s request.

For example, a search for a given piece of metadata on a search card will only work the database server, while first-time check-in will rely heavily on both the database and the archive or file server. More items can magnify those effects such as sorting routing style workflows with automatic transitions imposed on the initial state and the number of variables and attributes on data cards. All of these, among others, play a role in making a given task in SOLIDWORKS PDM not so immune to latency.

To best understand latency, we first need to define it in a controlled manner. Then, while controlling it, watch how various actions are affected inside SOLIDWORKS PDM. Only then can we evaluate the numbers and put some science to latency.

The Setup

For our study, we will use a common workstation, a Dell M6800 Precision Laptop for our client and for all our server needs. The specifics are not that necessary, as the only changes we are going to make are to latency. To do this, let’s use a simple tool called Clumsy version 0.2, an open source code readily available on the internet. Clumsy 0.2 is a program that, by design, imposes latency or slows packets of information on given ports. Think of it like adding signal or flagman in a construction zone.

In my examples I will slow the communications in terms of milliseconds (ms), varying from 0ms to 300ms on both the database and the archive or file server communication ports. Via the graphics in part one, we know that this will need to be done on ports 1433 and 3030. During the various latency settings I will document the time to complete a set of SOLIDWORKS PDM actions; drag and drop, check-in, searching, and transitioning using Windows 10 Steps Recorder.

The SOLIDWORKS test file set will be the somewhat familiar BBQ grill assembly used by many SOLIDWORKS students taking PDM user training. This dataset consists of approximately 50 files and is a little over 15MB. The SOLIDWORKS PDM Professional vault environment has a typical quick start data card for CAD files and no automatic transitions or actions taking place.

The Results

The polls have closed and the numbers are in. Below is a chart of my data. Listed across the top are the SOLIDWORKS PDM actions tested and listed down the side is the latency imposed on the two servers. The latency values are listed in milliseconds (ms) while the PDM actions tested are listed in seconds (s). Looking down the rows, the first row is for a “perfect world”, 0ms or no latency. The next group is with 50ms through 300ms of latency imposed on just the database server and so on.

For those in a larger organization, your database server is most likely not located in your facility. In fact, it is most likely in a data center at HQ or the corporate office while only a replicated archive server is located in your located facility. This is a very common architecture for international needs.

So let’s look a little closer at a specific area in the results charting that has a very high probability of affecting us all in the architecture as mentioned. Let’s look at the effects of imposing just a little bit of latency on the database server. 50ms is not too bad of a number, but it represents typical findings for clients that are a few hundred miles away from the database server.

Charting those numbers against perfect or “zero” latency for a more graphic representation, we quickly see how the database latency impacted by our check-in efforts while others remained nearly unchanged or immune. Again, remember what architecture would give us a lower database latency, it is one where the database server is nearby.

Now let’s take a look at adding some latency to both the database and the archive or file servers. This architecture is pretty common among mid-sized companies that don’t feel the need for replicated servers. Other plants or divisions might be geographically close by and, thus, no consideration was given to latency.

Conclusion

Various actions inside of SOLIDWORKS PDM have varying impacts on the database and archive or file servers. Users need to be mindful of this when recognizing latency is of concern and use it to look for specific functionality that imposes a less than efficient environment.

At the end of the day, most of our latency issues may not be resolvable but at least they can be documented and understood clearly and accepted by all. When latency starts to have a larger impact on our day-to-day efforts, users can use this understanding to be more exact on where the latency appears to be coming from and work with IT and your local SOLIDWORKS PDM administrator to determine repairs or improvements needed. Evaluate for an ROI, determine if investing in a replicated archive would have a quick payback. In the example above, it appears as though it most certainly should be.

Related Articles

SOLIDWORKS PDM Administrator 101: Topology & Latency (Part 1)

6 Considerations for Concluding a SOLIDWORKS PDM Latency Analysis (Part 3)

Are you Sure it’s a SOLIDWORKS PDM Permission?

About the Author

Joe Frank began using SOLIDWORKS and PDM back in 2008 and joined Fisher Unitech as an Applications Engineer in 2015. Joe has over 25 years of automotive tier one experience principally in the convertible top field. With his life experience and certifications as a PDM Administrator and Data Management Specialist, Joe brings a practical and enthusiastic approach to any PDM demonstration or implementation effort.