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

Are you a new SOLIDWORKS PDM administrator? Has your company grown in recent years?  Have divisions or facilities been added since SOLIDWORKS PDM was originally deployed?  If you answered yes to any of these questions, you are not alone. Companies in recent years have experienced many if not all of these changes. SOLIDWORKS PDM topology is something that can and does change over time, as companies grow the topology changes are sometimes minimal, while at other times they are significant. It may be time for you to review yours.

Within SOLIDWORKS PDM when the topology changes, the latency should be reviewed because users feel PDM is not responding fast enough to their requests whether they’re adding new files to the vault, updating information on a data card, or checking in a large assembly with several component changes. These setbacks can often get frustrating as finger-pointing between users and the folks in IT responsible for the infrastructure start talking about such topics. The fact of the matter is that latency is a real thing that does impact the day-to-day functionality within SOLIDWORKS PDM.

In this part one of a three-part blog series, we take a deeper dive into this impact on functionality by documenting times for day-to-day functionals while imposing a defined latency within the SOLIDWORKS PDM architecture. We’ll then take a closer look at the numbers to better understand where and to what degree does varying the latency really have on our daily lives in SOLIDWORKS PDM.

Before we get started, let’s first break out our technical dictionary and define some terms we’ll come across later on.

Latency

Latency is the delay before a transfer of data begins following an instruction for its transfer – ‘poor performance due to network latency.”

WAN

Wide Area Network (WAN) is a network that covers a broad area (i.e., any network that links across metropolitan, regional, or national boundaries). The Internet is the most popular WAN and is used by businesses, governments, non-profit organizations, individual consumers, artists, entertainers, and numerous others for almost any purpose imaginable.

In today’s world, many companies rely on a vast network to keep their employees communicating and collaborating on projects. A volume of data is transmitted across networks from department to department or even within a single department like Engineering, for example.

LAN

A Local Area Network is a computer network that interconnects computers in a limited area such as a home, school, computer lab, or office building using network media. The defining characteristics of a LAN, in contrast to a WAN (Wide Area Network), include their usually higher data-transfer rates, smaller geographic areas, and lack of a need for leased telecommunication lines.

Trace Route

A trace route or “tracert” is a utility that records the route (the specific gateway computers at each hop) through the Internet between your computer and a specified destination computer. It also calculates and displays the amount of time each hop took.

Ping

A ping test is a method of checking if the computer is connected to a network. It also determines the latency or delay between two computers.

Bandwidth

Bandwidth is normally expressed in Kilo, Mega, or Gigabits per second (the amount of data that can be transferred during a second).

Understanding SOLIDWORKS PDM Topology or Architecture

To better understand latency and how SOLIDWORKS PDM is impacted by it, we need to first understand the topology or architecture of PDM. Although there are several ways SOLIDWORKS PDM can be architected, there are four basic pieces that all SOLIDWORKS PDM environments must contain: clients, license server, database server, and the archive or file server.

In these environments, the connections are made either by a LAN or a combination of a LAN and a WAN configuration. In smaller organizations, the server pieces may all be on one server with the clients in the same building thus deploying nothing more than a LAN as the conduit.

In larger organizations, each piece may be on its own physical server with the clients in different locations around the world. Deployment with this type of strategy often requires the use of a replicated archive or file server along with both a LAN and a WAN configuration and, of course, the license and database servers.

More granularly, let’s understand the ports that SOLIDWORKS PDM communicates over with these four basic pieces. Regardless of the LAN and LAN/WAN configuration, all pieces must communicate over these ports.

For example, in the image below, we can see that clients will always communicate with the archive server over port 3030, and to the license server over ports 25734 or 25735. Now we can start to see how SOLIDWORKS PDM is “wired” and how or on what ports each of the pieces are communicating.

As we related these ports to typical architecture for larger international organizations, we can quickly see how some ports such as 1433 and 1434 can have a latency imposed naturally by the number of hops or the pure distance (mileage) between a given set of users and the database server. Quickly the tenured ePDM graphic image begins to make sense.

It doesn’t take much for us to image the number of hops there may be from users in China to get the database server here in the United States. Each of these hops represents the physical equipment that can, and does, impose a certain amount of latency. When you add them all up you can start to feel the pain as tasks take longer than expected to complete.

That wraps up this blog on SOLIDWORKS PDM latency and topology, in my next blog I’ll be describing how to perform a latency study. Stay tuned.

Related Articles

Performing a Latency Study in SOLIDWORKS PDM (Part 2)

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

Resetting the SOLIDWORKS PDM Administrator Password in SOLIDWORKS

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.