Showing results for 
Search instead for 
Do you mean 

NX Latency

Not sure this is the right place for  this question, so feel free to redirect.

Running NX with Tc.  Question came to me in regards to our network and reading and writing our NX files.

What is the speed of these read/writes, and are we completely optimized?


So my questions are

-How and Can I measure this?

-How do I determine if my findings are slow/normal/fast?




Re: NX Latency

The NX integration uses a local cache on the client in a 2-tier environment.

I don't know how this is configured in a 4-tier environment, but I assume there is also a local cache on the client.


The additional overhead compared to a native NX session, is the exchange of meta-data with the server in a managed NX session.


Generally the bare file operations should not be any different in a managed NX session compared to a native NX session.

Stefan Pendl, Systemmanager CAx, HAIDLMAIR GmbH
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 ( | TcVis 10.1
Development: VB.NET, Tcl/Tk    Testing: NX11.0 EAP, NX12.0 EAP

How to Get the Most from Your Signature in the Community

Re: NX Latency

My concern isn't on teh cache size, and correct me if I'm wrong, but when you perform a save, or a first time read, information is being pushed or pulled from a volume.  So what I am looking for is how to measure that latency.  And once finding that information, how can I determine if this is performing properly.



Re: NX Latency

I didn't talk about the cache size either Smiley Wink


Generally you can just use PING and see what latency you receive, use a bigger package size.

ping -l 1024 MyServer

In most cases only meta-data is transferred instantly, physical NX part files are transferred at a delay to reduce network traffic.

Stefan Pendl, Systemmanager CAx, HAIDLMAIR GmbH
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 ( | TcVis 10.1
Development: VB.NET, Tcl/Tk    Testing: NX11.0 EAP, NX12.0 EAP

How to Get the Most from Your Signature in the Community

Re: NX Latency

Hi Lindy,

This is somewhat of an open ended question, with a bunch of suggestions that are all going to be "relative" to your environment or what you/your users feel is adequate.


Latency, at least in the case that you are asking, is basically the time it takes to get from your clients to the volume. This can be <1ms if clients and volume servers are on the same LAN. If your clients are remote, your latency is impacted by numerous items (some under your control, others are just controlled by the laws of physics). Stefan gave a good example on how to get an idea of your latency via a ping. Keep in mind that if you are sending this command across a WAN and your company uses any sort of network prioritization or Quality of Service (QoS) hardware/software, ping may be very low on the priority list and latency could be higher than your actual NX data saves to the volume. Long story short, your network people should be able to help provide some of this data.


This information combined with the geographic distribution of your clients and data centers will help guide in configuring FMS in a manner to optimize the performance of your read/write activities for NX. Caching on the client and at each geographic site will tremendously impact your load times (after first load). Using network accelerators (Riverbeds) will help both read/write activities across a WAN.


There is no simple answer as to what is "normal". It all depends on your business case. How do you want/need to operate and what physical limitations (geographic or network/data center resourses) must you deal with will both play a role in "normal". Some of my locations only have a T1 WAN connection to our main data center, others have 5x's that. My local clients have <1ms latency to the volumes at our site, but if they need to access data that resides at a remote volume, that could be anywhere from 20ms-250ms. I wouldn't ask a whole facility of engineers to work on a 250ms latency network without a local volume, unless they weren't doing a lot of content creation, and even then, there would be things I'd do to minimize their pain. So many options, but I'll say it again, it all depends on your business case.


Hope some of that helps. If you can provide more specific details we can try to help more.

Re: NX Latency

Over the WAN a latency of below 150ms is recommended if I remember correctly.

Even with a local volume, you are always exchanging meta-data directly with the server, which has an impact on the performance experience of your users.

Stefan Pendl, Systemmanager CAx, HAIDLMAIR GmbH
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 ( | TcVis 10.1
Development: VB.NET, Tcl/Tk    Testing: NX11.0 EAP, NX12.0 EAP

How to Get the Most from Your Signature in the Community

Re: NX Latency

Max latency will depend on size of data that you are dealing with and where your volumes are located. I don't remember the current "max" latency for a 4tier client in NX, but with trick like only loading a product structure and opening components by proximity, you can get away with working on a higher latency network.


If you have thousands of components in your assemblies, you are going to need to play around with your work processes to make it functional.  


IMO, 4 Tier rich client performs pretty well over networks approaching 300ms latency, considering how slow that is. With NX, it is sensitive to latency to the database but also size of your BOMs, and the size of your CAD datasets (and their volume proximity to your clients).


It really depends on the business use case, because they can all have an impact to differing degrees. If I have a local volume and I'm opening a 5 part assembly that is 100mb (all datasets stored in the local volume) and I have a 200 ms latency to my DB, the assembly is still going to open pretty quickly because there isn't a lot of metadata work happening on the TCServer. If you have a really large assembly that is made up of small (disk size) components in the same network environment, it may end up taking longer because there is more metadata work going on (more communication to the DB).

Re: NX Latency

I purposely left this open ended.  My purpose is to just get my arms around how it is measured, and what is expected.  I recognize the network structure, size of cad objects, misc all have an impact.  Just want to be able at a minimum to set a baseline for our site.  e.g. Our largest assembly X, when read in with these options should only take X time.  My partners who are more CAD specialists than me have done a lot of things to make these reads quicker, and I think they have done a great job, but they also want to know is there more elsewhere that can be done.  But if don't establish a baseline, or some kind of "normal" expectation, we would never know what is proper.

I have gotten some information about how to check this, but looking to understand what this information is telling me too.

I was told to enter a system Environmental Variable of Time_User_Events with a value = to 1
Then told to read/save a model.  I can then look at the Menu-->Help-->Log file and I can find these entries:

READ TIME = Displayed in: CPU time:   0.078 secs, Real time: 0.124 secs


RM_save_part "%UL=V1.0 PH=xAGAAFydRX_VtA%MRN=000a": CPU time:   0.000 secs, Real time: 0.001 secs

CM_save_part "%UL=V1.0 PH=xAGAAFydRX_VtA%MRN=000a": CPU time:   0.000 secs, Real time: 0.000 secs

EXP_save_part "%UL=V1.0 PH=xAGAAFydRX_VtA%MRN=000a": CPU time:   0.000 secs, Real time: 0.000 secs

OCC_save_part "%UL=V1.0 PH=xAGAAFydRX_VtA%MRN=000a": CPU time:   0.000 secs, Real time: 0.001 secs

Saved KF partition: CPU time:   0.000 secs, Real time: 0.000 secs

Saved Basic "%UGMGR=V3.2 PH=xAGAAFydRX_VtA PRH=xEJAAFydRX_VtA PN=SKlindeja00029397 PRN=000a RT="has shape" AT="UG master part file" " itself, cpu   0.171, real   0.237


Now just trying to understand how can I use this as part of setting up my baseline tests. 


Re: NX Latency

Building a baseline can be as detailed as you need it to be. If you are interested in the whole picture, you can enable logging variables for TC that will give you similar feedback to your NX logging as to which specific operations are taking the most time. You will get details related to SQL performance, etc.


I'd first put together a simplier benchmark test. Pick a few assemblies of different size (BOM structure and actual file size) that you can open/load into NX. You will want to make sure you are dealing with apples to apples with all of your tests, so make sure you are using the same state of client cache (and server cache if you are at a remote site) for all the tests. The first load is going to always take longer if you don't have it cached. Then you can benchmark the time it takes to make a simple change and save to TC. You can also take an assembly and import to TC to get an idea of how long it takes to assign IDs, write to the volumes, etc. There are also tools that you can use to benchmark specific processes and load testing, but I don't think that is what you are looking for.


Once you have your specific use cases benchmarked (you can capture data from the logs, or just a stopwatch...they still work great), you can start going through your environment and make adjustments.


There are going to be certain things that are going to limit you depending on the versions of TC and NX that you are using. For example, when we upgraded from NX6 in Engineering to NX7.5 in TC UA, we saw substantial improvements in some of our processes (Progressive Die Wizard and Mold Wizard) in a 20ms latency WAN environment. Our project creation went from 7-15 minutes to 1-2 (or something in that neighborhood. I can't remember, that was a long time ago). Moral of the story is that they are constantly reducing the number of database calls in certain NX operations. This results in performance improvements. There are some presentations from PLM World (I think from Stewart Bresler) over the last few years that cover the specific operations and their improvements across TC and NX releases. If you are on an older version of NX and Teamcenter, consider some of the newer releases.


Here are some good documents to reference regarding performance (some are TC10 specific):

Client optimization

Network tuning

Jboss (if you use it)

SQL Server (if you use it)

Cache Sizing tool

Review the docs related to FMS configuration and settings. This can have a huge impact on performance if you are living in a WAN environment. Make sure FMS is setup to support your business needs.


This is a good start to performance analysis in general, and is what Siemens does for certain types of analysis activities. 


Hope that helps.


Re: NX Latency

Thank you for the input. It is fantastic!